JP2018195155A - Program, information processing apparatus, and information processing method - Google Patents

Abstract

To provide a program for effectively preventing an attack of malware, an information processing apparatus, and an information processing method.SOLUTION: A predetermined process is determined as ransomware when the following conditions are satisfied: an actual file on a disc is mapped on a memory as a virtual file corresponding to the actual file by a predetermined process (first condition); the virtual file is unmapped by the predetermined process (second condition); and file structure of the actual file or the virtual file at the time of unmapping is changed to be inappropriate (third condition).SELECTED DRAWING: Figure 71

Description

  The present invention relates to a program, an information processing apparatus, and an information processing method.

  In recent years, a type of malware called ransomware has become popular worldwide.

  Ransomware, like other common malware, infects devices via the Internet and email.

  Once the ransomware is infected, it encrypts (locks) some or all of the files on the device, makes it impossible to use the file or the device, and asks to pay a ransom. . It is a threatening malware that demands money in return for restoring encrypted files.

  In the case of ransomware, file encryption starts immediately after infection. For this reason, when the ransomware is an unknown sample for a security product, it is difficult to prevent file encryption because normal detection such as detection by a pattern file is not in time. Even if you notice ransomware infection at an early stage and immediately take measures such as turning off the power of the terminal, it is inevitable that some files will be encrypted by ransomware, and it is very difficult to completely prevent damage It is difficult to.

  As a method for detecting ransomware, operation of input interfaces such as a keyboard and a mouse is performed by utilizing a characteristic operation such as suddenly displaying a window regardless of a user's operation or an input state. A method for detecting a ransomware by monitoring a state and a change state of a display device is known (see Patent Document 1).

US Patent Application Publication No. 2014/0181971

  In the conventional method, it has been difficult to effectively prevent attacks such as file encryption by malware such as ransomware.

  An object of the present invention is to provide a program, an information processing apparatus, and an information processing method that can effectively prevent an attack by malware.

  In the program according to one aspect of the present invention, the file read function is already called from the predetermined process with respect to the same file path as the file write function to which the file write function called from the predetermined process writes data. Function as a determination unit that determines that the predetermined process is ransomware when the file write function satisfies the second condition that the file write function rewrites the header of the file in the file path. It is characterized by making it.

  In the above-described program, when the determination unit satisfies the third condition that the file of the file path is a text file having no header in addition to the first condition and the second condition. May present a user with a processing option as to whether or not to process the predetermined process as ransomware.

  In the above-described program, the determination unit includes, in addition to the first condition and the second condition, a path included in the file path from the predetermined process before the file write function is called. The predetermined process may be determined as ransomware when the fourth condition that a file search function for searching for another file in the same path is called is satisfied.

  In the above-described program, the determination unit is the same as the path included in the file path after calling the file write function from the predetermined process in addition to the first condition and the second condition. When the fifth condition is satisfied that the file movement function is called with the path of the file as the movement source path and the same path as the path included in the file path being called, The process may be determined as ransomware.

  In the program according to one aspect of the present invention, the file read function is already called from the predetermined process with respect to the same file path as the file path deleted by the file deletion function called from the predetermined process. The first condition and the second condition that the first file movement function having the same file path as the file path to be deleted by the file deletion function called from the predetermined process has already been called And a third condition that the file write function is already called from the predetermined process for the same file path as the source file path of the second file move function called from the predetermined process. And a file header of the file path of the movement source of the first file movement function, When the fourth condition that a file header of the file path to be deleted is different from the file path to be deleted by the file deletion function is made to function as a determination unit that determines the predetermined process as ransomware. And

  In the program according to one aspect of the present invention, the file read function is already called from the predetermined process with respect to the same file path as the destination file path of the file move function called from the predetermined process. A second condition that a file write function has already been called from the predetermined process for a file path that is the same as the file path that is the source of the file move function, and the file The predetermined process when the third condition that the header of the file path of the file path of the movement function is different from the header of the file path of the file path of the movement destination of the file movement function is satisfied. It is made to function as a judgment part which judges that is ransomware.

  In the program according to one aspect of the present invention, the file read function is already called from the predetermined process to the computer for the same file path as the file write function to which the file write function called from the predetermined process writes data. When the file write function satisfies the second condition that the file write function rewrites the header of the file in the file path, a procedure for determining the predetermined process as ransomware is executed. It is characterized by that.

  In the program according to one aspect of the present invention, the file read function is already called from the predetermined process for the same file path as the file path to be deleted by the file deletion function called from the predetermined process. The first condition and the second condition that the first file movement function having the same file path as the file path to be deleted by the file deletion function called from the predetermined process has already been called And a third condition that the file write function is already called from the predetermined process for the same file path as the source file path of the second file move function called from the predetermined process. And a file header of the file path of the movement source of the first file movement function, When the fourth condition that a file header of the file path to be deleted is different from the file header to be deleted by the file deletion function, a procedure for determining the predetermined process as ransomware is executed. To do.

  In the program according to one aspect of the present invention, the file read function is already called from the predetermined process for the same file path as the destination file path of the file move function called from the predetermined process. A second condition that a file write function has already been called from the predetermined process for a file path that is the same as the file path that is the source of the file move function, and the file The predetermined process when the third condition that the header of the file path of the file path of the movement function is different from the header of the file path of the file path of the movement destination of the file movement function is satisfied. Is executed as a ransomware.

  In the information processing apparatus according to one aspect of the present invention, the file read function is already called from the predetermined process with respect to the same file path as the file write function called from the predetermined process. And a determination unit that determines that the predetermined process is ransomware when the file write function satisfies a second condition of rewriting a header of a file in the file path. It is characterized by.

  In the information processing apparatus according to one aspect of the present invention, the file read function is already called from the predetermined process for the same file path as the file path to be deleted by the file deletion function called from the predetermined process. And a second condition that a first file movement function having the same file path as the file path to be deleted by the file deletion function called from the predetermined process has already been called. A third condition that a file write function has already been called from the predetermined process for the same file path as the source file path of the second file move function called from the predetermined process; , A file header of the source file path of the first file transfer function, and the file deletion When satisfying the fourth condition that the header of the file of the file path number is deleted is different, characterized by having a determining section for determining the predetermined process and ransomware.

  In the information processing apparatus according to one aspect of the present invention, the file read function is already called from the predetermined process for the same file path as the destination file path of the file move function called from the predetermined process. A first condition; a second condition that a file write function has already been called from the predetermined process with respect to a file path that is the same as a source file path of the file move function; and the file move When the third condition that the header of the file path of the file path to which the function is moved differs from the header of the file path of the file path to which the file movement function is moved is satisfied, the predetermined process is performed. It has a judgment part which judges as ransomware.

  In the information processing method according to one aspect of the present invention, the file read function is already called from the predetermined process with respect to the same file path as the file path in which the file write function called from the predetermined process writes data. The predetermined process is determined to be ransomware when the file write function satisfies the second condition of rewriting the header of the file in the file path. .

  According to an information processing method of one aspect of the present invention, a file read function is already called from the predetermined process for the same file path as the file path to be deleted by the file deletion function called from the predetermined process. And a second condition that a first file movement function having the same file path as the file path to be deleted by the file deletion function called from the predetermined process has already been called. A third condition that a file write function has already been called from the predetermined process for the same file path as the source file path of the second file move function called from the predetermined process; , A file header of the source file path of the first file transfer function, and the file deletion When satisfying the fourth condition that the header of the file of the file path number is deleted is different, and wherein the determining the predetermined process and ransomware.

  In the information processing method according to an aspect of the present invention, the file read function is already called from the predetermined process for the same file path as the destination file path of the file move function called from the predetermined process. A first condition; a second condition that a file write function has already been called from the predetermined process with respect to a file path that is the same as a source file path of the file move function; and the file move When the third condition that the header of the file path of the file path to which the function is moved differs from the header of the file path of the file path to which the file movement function is moved is satisfied, the predetermined process is performed. It is characterized by being determined as ransomware.

  A program according to an aspect of the present invention includes a first condition that a real file on a disk is mapped on a memory as a virtual file corresponding to the real file by a predetermined process; When the second condition that the virtual file is unmapped and the third condition that the file structure of the real file or the virtual file at the time of unmapping is changed to an inappropriate state, The predetermined process is caused to function as a determination unit that determines ransomware.

  A program according to an aspect of the present invention includes a first condition that a real file on a disk is mapped on a memory as a virtual file corresponding to the real file by a predetermined process, and the first condition is The predetermined condition is satisfied when a fourth condition that occurs continuously and a third condition that the file structure of the real file or the virtual file at the time of unmapping is changed to an inappropriate state are satisfied. The process is made to function as a determination unit that determines ransomware.

  In the above-described program, the third condition may be that header information of the real file at the time of mapping is different from header information of the real file or the virtual file at the time of unmapping.

  According to one aspect of the present invention, there is provided a program that causes a computer to map a real file on a disk as a virtual file corresponding to the real file on a memory by a predetermined process; The fifth condition that the program is not associated with the file type of the real file, and the sixth condition that the information of the real file at the time of mapping and the information of the real file or the virtual file at the time of unmapping are different. When the condition is satisfied, the predetermined process is made to function as a determination unit that determines to be ransomware.

  In the above-described program, the determination unit determines that the first condition is satisfied when an instruction to create the virtual file or an instruction to map the virtual file to the memory is called by the predetermined process. You may make it do.

  In the above-described program, the determination unit closes an instruction to unmap the virtual file from the memory, an instruction to write a part of the virtual file to the disk, or a handle of the virtual file by the predetermined process. When the instruction is called, it may be determined that the second condition is satisfied.

  In the above-described program, when the instruction to create the virtual file or the instruction to map the virtual file to the memory is continuously called by the predetermined process, the determination unit satisfies the fourth condition. You may make it judge that it is satisfied.

  In the above-described program, the computer further generates a backup file that backs up the real file when the real file is mapped on the memory as the virtual file by the predetermined process, and the determination unit performs the predetermined process. If the process is determined to be ransomware, the backup file may be made to function as a backup unit that writes back the backup file to the actual file on the disk.

  A program according to an aspect of the present invention relates to a seventh condition that a command to write to a real file on a disk is issued by a predetermined process, and the predetermined process is associated with the file type of the real file. When the eighth condition that the program is not a program is satisfied, the predetermined process is caused to function as a determination unit that determines to be ransomware.

  In the above-described program, the determination unit determines that the predetermined process is ransomware when the ninth condition that the file structure of the real file is changed to an inappropriate state by the write command is further satisfied. You may make it judge.

  A program according to an aspect of the present invention provides a computer with a first condition that a real file on a disk is mapped on a memory as a virtual file corresponding to the real file by a predetermined process, and the predetermined process When the second condition that the virtual file is unmapped and the third condition that the file structure of the real file or the virtual file at the time of unmapping is changed to an inappropriate state, A determination means for determining the predetermined process as ransomware is executed.

  A program according to an aspect of the present invention includes: a first condition that a real file on a disk is mapped on a computer as a virtual file corresponding to the real file by a predetermined process; The predetermined condition is satisfied when a fourth condition that occurs continuously and a third condition that the file structure of the real file or the virtual file at the time of unmapping is changed to an inappropriate state are satisfied. It is characterized in that a determination means for determining that the process is ransomware is executed.

  According to one aspect of the present invention, there is provided a program for causing a computer to map a real file on a disk as a virtual file corresponding to the real file on a memory by a predetermined process; The fifth condition that the program is not associated with the file type of the real file, and the sixth condition that the information of the real file at the time of mapping and the information of the real file or the virtual file at the time of unmapping are different. When the condition is satisfied, a determination means for determining the predetermined process as ransomware is executed.

  A program according to an aspect of the present invention relates to a seventh condition that a write command to a real file on a disk is issued to a computer by a predetermined process, and the predetermined process is associated with the file type of the real file. When the eighth condition that the program is not yet satisfied is satisfied, a determination means for determining the predetermined process as ransomware is executed.

  An information processing apparatus according to an aspect of the present invention includes a first condition that a real file on a disk is mapped on a memory as a virtual file corresponding to the real file by a predetermined process, and the virtual process is performed by the predetermined process. When the second condition that the file is unmapped and the third condition that the file structure of the real file or the virtual file at the time of unmapping is changed to an inappropriate state are satisfied, It has a judgment part which judges a predetermined process as ransomware.

  In the information processing apparatus according to one aspect of the present invention, the first condition that a real file on a disk is mapped on a memory as a virtual file corresponding to the real file by a predetermined process, and the first condition are continuous. The predetermined condition when the fourth condition that the file structure of the real file or the virtual file at the time of unmapping is changed to an inappropriate state is satisfied. It has the judgment part which judges a process as ransomware.

  An information processing apparatus according to an aspect of the present invention includes a first condition that a real file on a disk is mapped on a memory as a virtual file corresponding to the real file by a predetermined process, and the predetermined process is the real process. The fifth condition that the program is not associated with the file type of the file and the sixth condition that the information on the real file at the time of mapping and the information on the real file or the virtual file at the time of unmapping are different And a determination unit that determines that the predetermined process is ransomware.

  An information processing apparatus according to an aspect of the present invention relates to a seventh condition that a write command to a real file on a disk is issued by a predetermined process, and the predetermined process is associated with a file type of the real file. And a determination unit that determines that the predetermined process is ransomware when the eighth condition is satisfied.

  An information processing method according to an aspect of the present invention includes a first condition that a real file on a disk is mapped on a memory as a virtual file corresponding to the real file by a predetermined process, and the virtual process is performed by the predetermined process. When the second condition that the file is unmapped and the third condition that the file structure of the real file or the virtual file at the time of unmapping is changed to an inappropriate state are satisfied, The predetermined process is determined as ransomware.

  According to an information processing method of one aspect of the present invention, a first condition that a real file on a disk is mapped on a memory as a virtual file corresponding to the real file by a predetermined process, and the first condition is continuous. The predetermined condition when the fourth condition that the file structure of the real file or the virtual file at the time of unmapping is changed to an inappropriate state is satisfied. It is characterized by judging a process as ransomware.

  An information processing method according to an aspect of the present invention includes a first condition that a real file on a disk is mapped on a memory as a virtual file corresponding to the real file by a predetermined process, and the predetermined process is the real process. The fifth condition that the program is not associated with the file type of the file and the sixth condition that the information on the real file at the time of mapping and the information on the real file or the virtual file at the time of unmapping are different When the above conditions are satisfied, the predetermined process is determined as ransomware.

  An information processing method according to an aspect of the present invention relates to a seventh condition that a write command to a real file on a disk is issued by a predetermined process, and the predetermined process is associated with a file type of the real file. The predetermined process is determined to be ransomware when the eighth condition that the program is not included is satisfied.

  As described above, according to the present invention, the file read function is already called from the predetermined process with respect to the same file path as the file path in which the file write function called from the predetermined process writes data. Since the predetermined process is judged as ransomware when the condition 1 and the second condition that the file write function rewrites the header of the file in the file path are satisfied, the attack by the malware is effective. Can be prevented.

  According to the present invention, the first condition that a real file on the disk is mapped on the memory as a virtual file corresponding to the real file by a predetermined process, and the virtual file is unmapped by the predetermined process. And the third condition that the file structure of the real file or virtual file at the time of unmapping is changed to an inappropriate state is determined as the ransomware. As a result, it is possible to effectively prevent malware attacks.

It is a block diagram which shows a general information processing apparatus. It is explanatory drawing (the 1) which shows operation | movement of a computer program in relation to the hardware of a computer. It is explanatory drawing (the 2) which shows operation | movement of a computer program in relation to the hardware of a computer. It is explanatory drawing (the 1) of the file encryption by ransomware CryptoLocker regarding the principle (the 1) of this invention. It is explanatory drawing (the 2) of the file encryption by ransomware CryptoLocker regarding the principle (the 1) of this invention. It is explanatory drawing (the 3) of the file encryption by ransomware CryptoLocker regarding the principle (the 1) of this invention. It is explanatory drawing (the 4) of the file encryption by ransomware CryptoLocker regarding the principle (the 1) of this invention. It is explanatory drawing (the 1) of the file encryption by ransomware CryptoWall regarding the principle (the 1) of this invention. It is explanatory drawing (the 2) of the file encryption by ransomware CryptoWall regarding the principle (the 1) of this invention. It is explanatory drawing (the 3) of the file encryption by ransomware CryptoWall regarding the principle (the 1) of this invention. It is explanatory drawing (the 4) of the file encryption by ransomware CryptoWall regarding the principle (the 1) of this invention. It is explanatory drawing (the 5) of the file encryption by ransomware CryptoWall regarding the principle (the 1) of this invention. It is explanatory drawing (the 6) of the file encryption by ransomware CryptoWall regarding the principle (the 1) of this invention. It is explanatory drawing of the file encryption by ransomware CERBER regarding the principle (the 1) of this invention. It is explanatory drawing (the 1) of the file encryption by ransomware TeslaCrypt regarding the principle (the 1) of this invention. It is explanatory drawing (the 2) of the file encryption by ransomware TeslaCrypt regarding the principle (the 1) of this invention. It is explanatory drawing (the 1) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 2) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 3) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 4) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 5) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 6) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 7) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 8) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 9) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 10) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 11) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 12) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 13) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 14) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 15) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 16) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 17) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 18) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 19) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 20) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 21) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 22) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 23) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 24) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 25) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 26) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 27) explaining the program, information processing apparatus, and information processing method by 1st Embodiment of this invention. It is explanatory drawing (the 1) explaining the program, information processing apparatus, and information processing method by 2nd Embodiment of this invention. It is explanatory drawing (the 2) explaining the program, information processing apparatus, and information processing method by 2nd Embodiment of this invention. It is explanatory drawing (the 3) explaining the program, information processing apparatus, and information processing method by 2nd Embodiment of this invention. It is explanatory drawing (the 4) explaining the program, information processing apparatus, and information processing method by 2nd Embodiment of this invention. It is explanatory drawing (the 5) explaining the program, information processing apparatus, and information processing method by 2nd Embodiment of this invention. It is explanatory drawing (the 6) explaining the program, information processing apparatus, and information processing method by 2nd Embodiment of this invention. It is explanatory drawing (the 7) explaining the program, information processing apparatus, and information processing method by 2nd Embodiment of this invention. It is explanatory drawing (the 8) explaining the program, information processing apparatus, and information processing method by 2nd Embodiment of this invention. It is a figure explaining the difference of general file operation and file operation by file mapping regarding the principle (the 2) of this invention. It is a figure which shows the flow of the file operation at the time of the file encryption by ransomware Spora regarding the principle (the 2) of this invention. It is a figure which shows the relationship between the file operation by ransomware Spora, and hardware regarding the principle (the 2) of this invention. It is explanatory drawing (the 1) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 2) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 3) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 4) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 5) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 6) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 7) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 8) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 9) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 10) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 11) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 12) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 13) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 14) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 15) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 16) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 17) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 18) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 19) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 20) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 21) explaining the program, information processing apparatus, and information processing method by 3rd Embodiment of this invention. It is explanatory drawing (the 1) explaining the program, information processing apparatus, and information processing method by 4th Embodiment of this invention. It is explanatory drawing (the 2) explaining the program, information processing apparatus, and information processing method by 4th Embodiment of this invention. It is explanatory drawing (the 3) explaining the program, information processing apparatus, and information processing method by 4th Embodiment of this invention. It is explanatory drawing (the 4) explaining the program, information processing apparatus, and information processing method by 4th Embodiment of this invention. It is explanatory drawing (the 5) explaining the program, information processing apparatus, and information processing method by 4th Embodiment of this invention. It is explanatory drawing (the 6) explaining the program, information processing apparatus, and information processing method by 4th Embodiment of this invention. It is explanatory drawing (the 7) explaining the program, information processing apparatus, and information processing method by 4th Embodiment of this invention.

[Information processing device]
A general information processing apparatus to which the present invention is applied and its operation will be described with reference to FIGS.

  FIG. 1 is a block diagram showing a general information processing apparatus.

  The information processing apparatus 10 in a standard stand-alone environment includes a computer (PC) 20 and an external peripheral device 30.

  The computer (PC) 20 includes a CPU 21 for executing instructions, a hard disk 22 for storing data and programs, a memory 23 for the CPU 21 to read data and programs, and input / output such as a mouse and a keyboard for receiving user operations. The apparatus 24 is configured by a display 25 and the like for displaying operation contents, processing results, and the like.

  The external peripheral device 30 includes a printer 31 for printing processing results and the like, an external storage device 32 such as a USB memory, and the like.

  Next, with reference to FIG. 2 and FIG. 3, a series of operations in the case where a computer program, that is, a processing procedure to be performed by a computer written according to a predetermined format (program language) is executed in the computer 20 will be described. Description will be made in relation to hardware such as the CPU 21, the hard disk 22, and the memory 23.

  Before the computer 20 is started, OS data including programs and data of operation software (OS), programs to be executed by the computer 20, user data such as documents and drawings, and the like are stored in the hard disk 22 as files ( FIG. 2 (a)). In the memory 23, no program or data is developed.

  When the computer 20 is activated and the CPU 21 executes an instruction to load the OS data stored in the hard disk 22 into the memory 23, the OS data is expanded as a process on the memory 23 (FIG. 2B).

  Next, the CPU 21 executes a process of OS data on the memory 23, accesses a program stored in the hard disk 22, and reads the program (FIG. 2C). The program stored in the hard disk 22 is loaded into the memory 23 and expanded as a process on the memory 23 (FIG. 3A).

  Next, the CPU 21 executes a program process on the memory 23 to access user data stored in the hard disk 22 and read / write data from / to the hard disk 22 (FIG. 3B).

  In this way, operations among the CPU 21, the hard disk 22, and the memory 23 are performed by operation software and programs.

  In this specification, “process” means “a program developed on the memory 23”, and “program” means “a program (file) stored in a hard disk or the like”. For ease of understanding, “a program developed on the memory 23”, which is a “process”, may be simply referred to as “program”.

  Further, in this specification, “W” and “Ex” given at the end of the character string of the Windows API function have the same meaning as those not given. For example, “FindFirstFileW” is synonymous with “FindFirstFile”, and “MoveFileEx” is synonymous with “MoveFile”.

[Principle of the Invention (Part 1)]
The principle (part 1) of the present invention will be described with reference to FIGS.

(Ransomware analysis)
The inventors of the present application first analyzed the behavior related to file operations when performing file encryption on a plurality of main types of ransomware for which damage has been reported both in Japan and overseas. Specifically, we analyzed the behavior of four types of ransomware, CryptoLocker, CryptWall, CERBER, and TeslaCrypt.
(A) Analysis of Ransomware CryptoLocker The operation of ransomware CryptoLocker was analyzed using an analysis tool called API Monitor. The API monitor is a program that can monitor arguments and return values of a Windows API (Application Programming Interface) call called from an application without changing the application. Windows is a registered trademark.

  FIG. 4 shows an API log called when encrypting a file of the ransomware CryptoLocker. This is a log when files in the folder "C: \ Python27 \ Lib \ compiler" are sequentially encrypted by the ransomware CryptoLocker.

  FindNextFile on the first line is a Windows API function that searches for the next file.

  CreateFileW on the second line is a Windows API function that opens the file with the argument "C: \ Python27 \ Lib \ compiler \ consts.py".

  ReadFile on line 3-4 is a Windows API function that reads the file “C: \ Python27 \ Lib \ compiler \ consts.py” opened by CreateFileW.

  WriteFile on line 5-7 is a Windows API function that writes data to the file “C: \ Python27 \ Lib \ compiler \ consts.py” opened by CreateFileW.

  The log on the 1-7th line indicates the following.

  FindNextFile is searched with FindNextFile on the first line, and the file with the argument "C: \ Python27 \ Lib \ compiler \ consts.py" is opened with CreateFileW on the second line. ReadFile and 5-7 on lines 3-4 The file "C: \ Python27 \ Lib \ compiler \ consts.py" is encrypted by WriteFile on the line.

  FindNextFile on the 8th line is a Windows API function that searches for the next file.

  The CreateFileW on the 9th line is a Windows API function that opens the file with the argument “C: \ Python27 \ Lib \ compiler \ future.py”.

  ReadFile on line 10-11 is a Windows API function that reads the file “C: \ Python27 \ Lib \ compiler \ future.py” opened by CreateFileW.

  WriteFile on the 12th to 15th lines is a Windows API function for writing data to the file “C: \ Python27 \ Lib \ compiler \ future.py” opened by CreateFileW.

  The logs on the 8th to 15th lines indicate the following.

  Search for the next file using FindNextFile on the 8th line, and open the file with the argument "C: \ Python27 \ Lib \ compiler \ future.py" using CreateFileW on the 9th line. ReadFile and 12-15 on the 10-11th line WriteFile on the line encrypts the file "C: \ Python27 \ Lib \ compiler \ future.py".

  FindNextFile on the 16th line is a Windows API function that searches for the next file.

  CreateFileW on the 17th line is a Windows API function that opens a file with an argument “C: \ Python27 \ Lib \ compiler \ misc.py”.

  ReadFile on the 18th to 19th lines is a Windows API function that reads the file “C: \ Python27 \ Lib \ compiler \ misic.py” opened by CreateFileW.

  WriteFile on lines 20-22 is a Windows API function that writes data to the file “C: \ Python27 \ Lib \ compiler \ misic.py” opened by CreateFileW.

  The log on lines 16-22 indicates the following.

  The next file is searched by FindNextFile on the 16th line, the file of the argument “C: \ Python27 \ Lib \ compiler \ misic.py” is opened by CreateFileW on the 17th line, ReadFile and 20-22 on the 18th to 19th lines WriteFile on the line encrypts the file "C: \ Python27 \ Lib \ compiler \ misic.py".

  Similarly, the files in the folder "C: \ Python27 \ Lib \ compiler \" are sequentially encrypted.

From this log, you can see that the ransomware CryptoLocker encrypts files as follows:
(1) Search for a file using FindFirstFile and FindNextFile. FindFirstFile and FindNextFile are search Windows API functions used in the set.
(2) Open the file to be encrypted with CreateFile.
(3) For the opened file, rewrite and encrypt the file with ReadFile and WriteFile. That is, ReadFile reads the file contents of the encryption target file, the malware encrypts the read encryption target file contents, and writes the encrypted data to the original encryption target file by WriteFile.

  FIG. 5 shows a log of an API called at the time of file encryption of the ransomware CryptoLocker. This is a log when the file "Wildlife.wmv" under the folder "C: \ User \ Public \ Videos" is searched and encrypted by the ransomware CryptoLocker.

  FindFirstFile on the third line is a Windows API function that searches for the first file of the argument “C: \ Users \ Public \ Videos \ *. *”.

  FindNextFile on line 4-9 is a Windows API function that searches for the next file.

  FindFirstFile on the 10th line is a Windows API function that searches for the first file of the argument “C: \ Users \ Public \ Videos \ Sample Videos \ *. *”.

  FindNextFile on the 11th to 13th lines is a Windows API function that searches for the next file.

  The CreateFileW on the 14th line is a Windows API function that opens the file of the argument “C: \ Users \ Public \ Videos \ Sample Videos \ Wildlife.wmv”.

  ReadFile on the 15th to 16th lines is a Windows API function that reads the file “C: \ Users \ Public \ Videos \ Sample Videos \ Wildlife.wmv” opened by CreateFileW.

  WriteFile on the 17th to 19th lines is a Windows API function for writing data to a file “C: \ Users \ Public \ Videos \ Sample Videos \ Wildlife.wmv” opened by CreateFileW.

  FindNextFile on the 20th line is a Windows API function that searches for the next file.

  The log on lines 3-9 indicates the following.

  A file in the folder “C: \ Users \ Public \ Videos \ *. *” Is searched by FindFirstFile on the 3rd line and FindNextFile on the 4th-9th line, but the file is not found.

  The logs on lines 10-14 indicate the following.

  With FindFirstFile on the 10th line, the folder "C: \ Users \ Public \ Videos \ *. *" Is moved to a lower folder "C: \ Users \ Public \ Videos \ Sample Videos \ *. *", And 11-13 FindNextFile on the line searched the folder "C: \ Users \ Public \ Videos \ Sample Videos \ *. *" And found the file "C: \ Users \ Public \ Videos \ Sample Videos \ Wildlife.wmv" So, open with CreateFileW on the 14th line.

  The logs on the 15th to 20th lines indicate the following.

  The file "C: \ Users \ Public \ Videos \ Sample Videos \ Wildlife.wmv" opened by CreateFileW is encrypted using ReadFile on the 15th to 16th lines and WriteFile on the 17th to 19th lines.

  Then, the next file in the folder “C: \ Users \ Public \ Videos \ Sample Videos \ *. *” Is searched by FindNextFile on the 20th line.

  As shown in Fig. 5, when a file under a certain folder is searched and encrypted, the file is searched using FindFirstFile, FindNextFile, CreateFile, ReadFile, and WriteFile as in Fig. 4, and the searched file is rewritten. To encrypt.

  FIG. 6 shows the state of the file “Wildlife.wmv” before and after being accessed by the ransomware CryptoLocker. FIG. 6A shows a state before being accessed by the ransomware CryptoLocker, and FIG. 6B shows a state after being accessed by the ransomware CryptoLocker.

  As shown in FIG. 6, after being accessed by the ransomware CryptoLocker, the header of the encrypted file “Wildlife.wmv” is rewritten.

  FIG. 7 shows the header of the file “Wildlife.wmv” before and after being encrypted by the ransomware CryptoLocker. FIG. 7A shows a header before being encrypted by the ransomware CryptoLocker, and FIG. 7B shows a header after being encrypted by the ransomware CryptoLocker.

  As shown in FIG. 7, all bytes from the beginning to the end of the file “Wildlife.wmv” are rewritten. At least in the case of a binary file, the part called “header” (typically several bytes to several tens of bytes from the beginning) representing the information of various types of information according to the file type, size, and file type has been rewritten. .

From the above, it was found that the behavior related to file operations during encryption of the ransomware CryptoLocker is as follows.
(1) FindFirstFile and FindNextFile, which are Windows API functions for file search, are called.
(2) CreateFile, a Windows API function that opens a file, is called.
(3) ReadFile, which is a Windows API function that reads a file, and WriteFile, which is a Windows API function that writes data to the file, are called to the target file of CreateFile.
(4) The target file header of CreateFile is different before and after the access of ransomware CryptoLocker.
(B) Analysis of ransomware CryptoWall The operation of ransomware CryptoWall was analyzed using a debugger (Debugger) which is a program that supports program debugging.

  The ransomware CryptoWall first searches for files in the terminal from the root drive using FindFirstFileW, which is a Windows API function for searching for files.

  FIG. 8 is a screen capture of the debugger showing how the ransomware CryptoWall starts searching for a file.

  The first capture in FIG. 8A shows that “C: \ *”, which is the root of the drive, is passed to FindFirstFileW as an argument.

  The next capture in FIG. 8B shows that “C: \ Users \ *”, which is a folder below the root “C: \ *” of the drive, is passed to FindFirstFileW as an argument.

  The next capture shown in Fig. 8 (c) shows that "C: \ Users \ Publice \ *", which is a folder lower than the folder "C: \ Users \ *", is passed to FindFirstFileW as an argument. ing.

  In the next capture shown in FIG. 8D, “C: \ Users \ Publice \ Videos \ *”, which is a folder below the folder “C: \ Users \ Public \ *”, is passed to FindFirstFileW as an argument. It shows that.

  As a result of further file search in the terminal from the root drive by the Windows API function FindFirstFileW, "C: \ Users \ Public \ Videos \ Sample Videos \ Wildlife.wmv" is first searched and encrypted by the ransomware CryptoWall Is done.

  FIG. 9 is a screen capture of the debugger showing how the ransomware CryptoWall encrypts the file “C: \ Users \ Public \ Videos \ Sample Videos \ Wildlife.wmv”.

  The first capture in FIG. 9A shows that the file “C: \ Users \ Public \ Videos \ Sample Videos \ Wildlife.wmv” has been opened by the Windows API function CreateFileW.

  In the next capture in Fig. 9 (b), the Windows API function ReadFile and the Windows API function WriteFile are called alternately, and the file "C: \ Users \ Public \ Videos \ Sample Videos \ Wildlife.wmv" It shows that the data is rewritten and encrypted by a predetermined size.

  The next capture shown in Fig. 9 (c) is the Windows API function MoveFile called, and the original file "C: \ Users \ Public \ Videos \ Sample Videos \ Wildlife.wmv" is encrypted. Indicates that the file name has been changed to another file name.

  FIG. 10 shows the state of the file “Wildlife.wmv” before and after being accessed by the ransomware CryptoWall. FIG. 6A is a state before being accessed by the ransomware CryptoWall, and FIG. 6B is a state after being accessed by the ransomware CryptoWall.

  As shown in FIG. 10, after being accessed by the ransomware CryptoWall, the original file name “wild animal.wmv (Wildlif.wmv in the folder“ C: \ Users \ Public \ Videos \ Sample Videos \ *. * ” ) "Has been changed to a different file name, and the file header has been rewritten.

  FIG. 11 shows the header of the file “Wildlife.wmv” before and after being encrypted by the ransomware CryptoWall. FIG. 11A shows a header before being encrypted by the ransomware CryptoLocker, and FIG. 11B shows a header after being encrypted by the ransomware CryptoLocker. The file name of the encrypted file has been changed.

  As shown in FIG. 11, all bytes from the beginning to the end of the file “Wildlife.wmv” are rewritten. At least in the case of a binary file, the part called “header” (typically several bytes to several tens of bytes from the beginning) representing the information of various types of information according to the file type, size, and file type has been rewritten. .

  Next, how to encrypt another file will be described.

  12 and 13 are screen shots of the debugger showing how the ransomware CryptoWall encrypts the file “C: \ Users \ Public \ Pictures \ Sample Pictures \ Tulips.jpg”.

  The first capture in FIG. 12A shows that the file “C: \ Users \ Public \ Pictures \ Sample Pictures \ Tulips.jpg” has been opened by the Windows API function CreateFile.

  The next capture in FIG. 12B shows that ReadFile, which is a Windows API function, and WriteFile, which is a Windows API function, are repeatedly called.

  The next capture in FIG. 13 shows that the file “C: \ Users \ Public \ Pictures \ Sample Pictures \ Tulips.jpg” is damaged by encryption and cannot be displayed as a thumbnail. Furthermore, the Windows API function MoveFileEX is called, and the original file "C: \ Users \ Public \ Pictures \ Sample Pictures \ Tulips.jpg" is another file name after encryption "C: \ Users \ Public \ Pictures \ Sample Pictures \ p3EiSzLkWhfU5pgrD5SX9PdYPyP5ICa5iXzySi34oaY = .E08A29776586FC717E27.breaking_bad ".

From the above, it was found that the behavior related to file operations during encryption of ransomware CryptoWall is as follows.
(1) FindFirstFile and FindNextFile, which are Windows API functions for file search, are called.
(2) CreateFile, a Windows API function that opens a file, is called.
(3) ReadFile, which is a Windows API function that reads a file, and WriteFile, which is a Windows API function that writes data to the file, are called to the target file of CreateFile.
(4) The target file header of CreateFile is different before and after the access of ransomware CryptoWall.
(5) MoveFileEx, which is a Windows API function for moving files, is called, and the file name is changed with the same movement destination.
(C) Analysis of ransomware CERBER The operation of ransomware CERBER was analyzed using a debugger (Debugger) which is a program that supports program debugging.

  The ransomware CERBER first searches for a file in the terminal by using FindFirstFile and FindNextFile, which are Windows API functions for searching for a file, and creates a list in advance with a file having a specific extension as an encryption target file.

  Next, after opening the listed files to be encrypted in turn with the Windows API function CreateFileW, read the file once with the Windows API function ReadFile, and then write the data to the file with the Windows API function WriteFile. Encryption. Further, when encryption is completed by writing data by WriteFile, the file is moved to the same folder, that is, the file name is changed by MoveFileW which is a Windows API function.

  FIG. 14 is a screen capture of the debugger showing how the ransomware CERBER encrypts a file.

  The first capture in FIG. 14A shows that the file “C: \ Python27 \ Lib \ unittest \ test \ test_assertions.py” is opened by the Windows API function CreateFileW.

  The next capture in FIG. 14B shows that a file opened with CreatFileW is read by ReadFile, which is a Windows API function.

  Further, the next capture in FIG. 14C shows that WriteFileW writes data to a file opened by WriteFile which is a Windows API function.

  Further, the capture shown in FIG. 14D shows that MoveFileW, which is a Windows API function, is called, and the file name of the file opened by CreatFileW is changed.

From the above, it was found that the behavior related to file operations during encryption of ransomware CERBER is as follows.
(1) CreateFile, a Windows API function for file search, is called.
(2) ReadFile, which is a Windows API function that reads a file, and WriteFile, which is a Windows API function that writes data to the file, are called to the target file of CreateFile.
(3) The header of the target file of CreateFile is different before and after the access of ransomware CERBER.
(4) MoveFileEx, which is a Windows API function for moving files, is called, and the file name is changed with the same movement destination.
(D) Analysis of ransomware TeslaCrypt The operation of ransomware TeslaCrypt was analyzed using a debugger (Debugger) which is a program that supports program debugging.

  The ransomware TeslaCrypt first searches for a file in the terminal from directly under the C drive by using FindFirstFile and FindNextFile which are Windows API functions for searching for a file. If there is a file with a specific extension that is the file to be encrypted, it is opened with the Windows API function CreateFileW, then the Windows API function ReadFile is executed multiple times to read the file on the memory, and the memory Encrypt the above file, and then execute the Windows API function WriteFile multiple times to overwrite the file to be encrypted.

  FIG. 15 is a screen shot of the debugger showing how the ransomware TeslaCrypt encrypts a file.

  The first capture in FIG. 15A shows that a file in the terminal is searched from directly under the C drive by the Windows API functions FindFirstFile and FindNextFile.

  The next capture in FIG. 15B shows that the file “C: \ Users \ test \ Desktop \ Decoy.png” has been opened by the Windows API function CreateFileW.

  Further, the next capture shown in FIG. 15C shows that the file opened by CreatFileW is read in a plurality of times by ReadFile which is a Windows API function.

  Further, the next capture shown in FIG. 15D shows that data is written in multiple times in the file opened by CreatFileW by WriteFile, which is a Windows API function.

  FIG. 16 shows the header of the file “C: \ Users \ test \ Desktop \ Decoy.png” before and after being encrypted by the ransomware TeslaCrypt. FIG. 16A is a header before being encrypted by the ransomware TeslaCrypto, and FIG. 16B is a header after being encrypted by the ransomware TeslaCrypto.

  As shown in FIG. 16, all bytes from the beginning to the end of the file “Decoy.png” are rewritten. At least in the case of a binary file, the part called “header” (typically several bytes to several tens of bytes from the beginning) representing the information of various types of information according to the file type, size, and file type has been rewritten. .

From the above, it was found that the behavior related to file operations during encryption of ransomware TeslaCrypt is as follows.
(1) FindFirstFile and FindNextFile, which are Windows API functions for file search, are called.
(2) CreateFile, a Windows API function for file search, is called.
(3) ReadFile, which is a Windows API function that reads a file, and WriteFile, which is a Windows API function that writes data to the file, are called to the target file of CreateFile.
(4) The target file header of CreateFile is different before and after the access of ransomware TeslaCrypt.

(Principle of the present invention)
The inventors of the present application have noticed from the analysis results of these four types of ransomware that the file operation behavior when encrypting a file has the following common behavior.
(1) CreateFile, a Windows API function that opens a file, is called.
(2) ReadFile and WriteFile, which are Windows API functions, are called at least once for the target file of CreateFile.
(3) The header of the target file of CreateFile has changed.

  It is difficult to imagine a general application that behaves like this, and this behavior is unique to ransomware.

  Therefore, the inventors of the present application can detect an unknown ransomware that attempts to encrypt a file by detecting such a behavior, and can effectively prevent an attack by the unknown ransomware. Have come up with the idea of the present invention.

[First Embodiment]
A program, an information processing apparatus, and an information processing method according to the first embodiment of the present invention will be described with reference to FIGS.

(Outline of this embodiment)
The outline of the present embodiment will be described with reference to FIGS. 17 and 18.

  In the present embodiment, all behaviors of a program having a behavior of accessing user data stored in the hard disk 22 are detection targets.

  The CPU 21 executes a process of OS data on the memory 23, accesses a program stored in the hard disk 22, reads the program (FIG. 2C), and stores the program stored in the hard disk 22 in the memory 23. Before being loaded and expanded as a process on the memory 23 (FIG. 3A), the process of the program of the present invention is made resident in the memory 23 (FIG. 17A).

  The program of the present invention may be executed at any time before the ransomware is in danger of being introduced and may be made resident as a process in the memory 23.

  For example, it is started as a startup program when the computer is started. The Windows OS has a mechanism that allows a “startup program” to be registered as a program that is executed when the PC is started. In the present embodiment, the program of the present invention is registered as a startup program using the mechanism. As a result, the program of the present invention is placed on the memory 23 immediately after the PC is started.

  In addition, as a method of starting a program when the PC is started, there is a method of using a registry or a service mechanism, but any method may be used.

  As a result, the computer can always be protected from ransomware immediately after the PC is started.

  As shown in FIG. 17A, the program of the present invention interrupts between an operation in which the program stored in the hard disk 22 is loaded into the memory 23 and an operation in which the CPU 21 executes the program. By hooking the operation based on the program by the CPU 21, the behavior of the program is placed under the monitoring of the program of the present invention immediately before the program is executed.

  Thereby, thereafter, all behaviors of the monitoring target program can be grasped immediately before execution of the program of the present invention. As necessary, functions can be added to or changed in the processing of the monitoring target program.

  When it is determined by the program of the present invention that the behavior of the monitoring target program is unique to the ransomware, as shown in FIG. 17B, the monitoring target program is stored in the hard disk 22 as shown in FIG. Block access just before trying to access the file. In this way, attacks by unknown ransomware are blocked to prevent file encryption.

  The program of the present invention has three functions. Three functions of the program of the present invention will be described with reference to FIG.

  The first function is a function for hooking a Windows API used by a currently running program or a monitoring target program that is a program to be activated later. As shown in FIG. 18, from the program of the present invention, a currently running process, that is, a notepad.exe, WINWORD.exe, calc.exe, Ramsomware.exe, cmd.exe,... To do.

  The second function is a function of notifying and inquiring of the program of the present invention the behavior of the monitored program by the hooked Windows API, and determining whether the monitored program is ransomware based on the result.

  The third function is a function that responds to receipt, recording, and inquiry of notification from the hooked Windows API.

  The first function and the third function are functions of the resident program of the present invention, and the second function is a function of the program of the present invention incorporated in the monitoring target program.

(Windows API function to be hooked)
The program of the present invention realizes detection and protection of ransomware by hooking a Windows API function, which is a common behavior obtained from the analysis result of ransomware, in the process to be monitored.

  As pointed out in the principle of the present invention, the Windows API function that is a common behavior of ransomware is CreateFile (file creation function (file handle acquisition function)), (file generation function), ReadFile (file read function), WriteFile (file write function).

  In this embodiment, CreateFile (file creation function) for opening a file and acquiring a file handle, which is a common Windows API function, is not a hook target, only ReadFile (file read function) and WriteFile (file write function). Is a hook target. The reason is as follows.

  First, in order to execute the common Windows API functions, such as ReadFile (file read function) and WriteFile (file write function), it is essential to obtain a file handle in advance. It is possible to detect that the handle of the file is acquired simply by setting the file reading function) and WriteFile (file writing function) as a hook target.

  In addition, since the file handle can be obtained with Windows API functions other than CreateFile (file creation function), for example, OpenFile (file open function), CreateFile (file creation function) It is not a Windows API function that is essential to obtain.

(HookReadFile)
HookReadFile is a Windows API function that hooks ReadFile (file read function).

  HookReadFile is a Windows API function to which the function of notifying the following information (a) to (c) is added to the program of the present invention in addition to the normal operation of ReadFile.

As the notification means, a high-speed method that does not cause a large delay in the operation of the process, such as inter-process communication, is desirable. Any method may be used as long as the environment can be realized at high speed, such as socket communication or file delivery.
(A) Notification source API name. ReadFile, the name of the Windows API function to hook.
(B) its own process ID; This is the process ID of the monitored process that calls the hooked ReadFile.
(C) Target file path of ReadFile. This is a file path indicating a file handle specified in a parameter of ReadFile that is a notification source API.

  Here, the “file path” includes a “path” of folders that are layered up to the “folder” in which the “file” is stored. For example, the “file path” of the file “note.doc” in the folder “Desktop” in the folder “user” in the folder “Users” on the “C drive” of the hard disk is as follows.

C: \ Users \ user \ desktop \ note.doc
Also, the file path (C: \ Users \ user \ desktop \) excluding the file name (note.doc) from the file path (C: \ Users \ user \ desktop \ note.doc) say.

  Receiving notification from HookReadFile (ReadFile hook function), the program of the present invention sequentially stores the notified contents, that is, the API name, process ID, and file path in the memory 23 as notification record data. This notification record data is used in HookWriteFile (WriteFile hook function) described later.

  Since the operating system has a function of reusing process IDs, there is a possibility that the same process ID may be accidentally assigned to different processes if the process ID continues for a long time. In order to prevent such erroneous detection of ransomware due to an accidental process ID match, it is desirable to periodically clear the notification record data.

  Although the interval for periodically clearing the conference record data is arbitrary, it is desirable to clear it at the end of the operating system or at the restart. The clear interval may be set by the user.

  FIG. 19 shows an image of the operation by the above HookReadFile. The left part of FIG. 19 shows the process of the monitoring target program, and the right part of FIG. 19 shows the process of the program of the present invention.

  The process of the monitoring target program on the left side of FIG. 19 incorporates HookReadFile which is a hook function of the program of the present invention. The incorporated HookReadFile notifies (a) the notification source API name, (b) its own process ID, and (c) the ReadFile target file path to the process of the present invention on the right side of FIG. 19 in addition to the normal ReadFile operation. .

  The process of the present invention program on the right side of FIG. 19 responds to notifications from HookReadFile. The notification from the HookReadFile on the left side of FIG. 19 is received and sequentially recorded as notification record data.

  In FIG. 19, HookReadFile includes (a) [NotFile] API name, (b) own process ID, (c) ReadFile target file path, (a) [ReadFile], (b) pid: 3421, and (c) filename. : c: \ Users \ user \ Desktop \ note.doc; (a) [ReadFile], (b) pid: 1568, and (c) filename: c: \ Users \ user \ Documents \ schedule.xls; (A) [ReadFile], (b) pid: 1568 and (c) filename: c: \ Users \ user \ Documents \ schedule.xls Are recorded as notification record data.

(HookWriteFile)
HookWriteFile is a Windows API function that hooks WriteFile (file write function).

  HookWriteFile is a Windows API function that adds the following functions to the normal WriteFile operation.

  If the parameters specified in WriteFile and the information that can be acquired from the parameters match the “criteria for file encryption operation by ransomware” described later, it is determined that the file encryption operation is by ransomware, and WriteFile A function that terminates the process without writing the data.

  The above “determination criteria for file encryption operation by ransomware” means that the following conditions (A) to (C) are satisfied.

  Condition (A): The current position of the file pointer of the file handle specified as the write target of WriteFile is acquired, and the current position is within the head or header range. The current position of the file pointer can be obtained by using the SetFilePointer function.

  Condition (B): Data changes before and after rewriting by calling WriteFile.

  Condition (C): As a result of inquiring the program of the present invention, ReadFile has already been called from its own process for the file specified when WriteFile is called.

  Based on the condition (A) and the condition (B), it is determined whether the head of the file or the information in the header range has changed.

  The reason for including the condition (C) is as follows.

  In a general file encryption procedure, as a method for implementing a program, a method of encrypting the content read by ReadFile and then directly writing to another file by WriteFile is employed. However, the ransomware analyzed this time did not take such a technique, and rewritten the file read by ReadFile with WriteFile, and then renamed it. This is considered to prevent file restoration by the forensic technique. By overwriting the file read with ReadFile with WriteFile, the data on the disk is overwritten. Therefore, there is a high possibility that the file cannot be restored even by a method using forensic technology. The author of ransomware seems to be aiming for the situation. In the program of the present invention, this behavior is one of the detection conditions, so it is very effective for such ransomware characteristics.

  With this added function, HookWriteFile (WriteFile hook function) determines whether the calling process is ransomware. If it is ransomware, it prevents file encryption, ransomware detection notification, and ransomware process. Can be forcibly terminated.

  An image of condition (A) is shown in FIG.

  The left part of FIGS. 20A and 20B shows the process of the monitoring target program on the memory 23, and the right part of FIGS. 20A and 20B shows the write target file on the hard disk 22.

  A write start position to the write target file on the hard disk 22 is designated from the HookWriteFile incorporated in the monitoring target process on the memory 23.

  In the case of FIG. 20A, the write start position “0x00000020” for the upper write target file on the hard disk 22 is not the start of the file, and the write start position “0x00000000” for the lower write target file is the start of the file. . It is determined that the writing to the lower writing target file whose writing start position is the head of the file satisfies the condition (A) and there is a possibility of writing by ransomware.

  In the case of FIG. 20B, the write start position “0x00000024” for the upper write target file on the hard disk 22 is not within the range of the file header, and the write start position “0x00000004” for the lower write target file is the file. It is not at the beginning but is within the range of the header. It is determined that writing to the lower writing target file whose writing start position is within the range of the file header satisfies the condition (A) and there is a possibility of writing by ransomware.

  In order to determine whether it is within the header range, the header size for each extension of the file needs to be known in advance. The size of the header corresponding to each extension is stored in advance in HookWriteFile (WriteFile hook function). For example, in the PDF file with the extension “pdf”, the first 5 bytes are the header.

  An image of the condition (B) is shown in FIG.

  The left part of FIG. 21 shows the process of the monitoring target program on the memory 23, and the right part of FIG. 21 shows the write target file on the hard disk 22.

  The write-scheduled data to be written by the HookWriteFile incorporated in the monitoring target process on the memory 23 is compared with the data before the writing of the write target file on the hard disk 22.

  In the case of FIG. 21, the data to be written “00 AA 00 BB 00 CC 00 DD 00 EE 00 FF 00 00 08 00” to be written by HookWriteFile and the data before writing of the write target file on the hard disk 22 “50 4B Since 03 04 14 00 06 00 08 00 00 00 21 00 A3 EF ", it is judged that the condition (B) is satisfied and there is a possibility of writing by ransomware.

  An image of the condition (C) is shown in FIG.

  22A shows the process of the monitoring target program on the memory 23 on the left side, and FIG. 22A shows the process of the program of the present invention on the memory 23 on the right side.

  The hook write file incorporated in the monitoring target process on the left side of FIG. 22 (a) is based on the process ID of itself (monitoring target process) and the target file path of WriteFile. The process is inquired of whether there is a record of ReadFile with the same process ID and the same target file path in ReadFile notification record data. The program of the present invention on the right side of FIG. 22 responds to HookWriteFile whether there is a record of ReadFile with the same process ID and the same target file path.

  In the case of FIG. 22A, ReadFile notification record data based on the process ID “pid: 1568” and the file path “C: \ Users \ user \ Documents \ schedule.xls” from the HookWriteFile embedded in the monitored process. Inquire against.

  FIG. 22B shows the notification record data of ReadFile.

  Lines 4-6, 7-9, and 13-15 of ReadFile notification record data show the HookWriteFile process ID “pid: 1568” and file path “C: \ Users \ user \ Documents \ schedule.xls”. Since there is a ReadFile record with the same process ID “pid: 1568” and file path “C: \ Users \ user \ Documents \ schedule.xls”, the condition (C) is satisfied and the ransomware writes It is determined that there is a possibility.

  As a result, the program of the present invention on the right side of FIG. 22A responds to HookWriteFile that ReadFile of the same process ID and the same target file path has been recorded.

(Exclusion list)
Hooking all ReadFile and WriteFile called from all processes running on the system and determining whether the process is ransomware adds a new load to the system. .

  Therefore, in this embodiment, an “exclusion list” in which programs that are clearly not ransomware are registered in advance is created, and the program of the present invention is not executed for the programs registered in the exclusion list.

  FIG. 23 shows a specific example of the exclusion list.

  Regular programs are registered in the exclusion list. For example, “program name”, “program file”, “full file path”, “file size”, “hash value”, “digital signature”, and the like installed in the system are registered as necessary.

  In FIG. 23, “Internet Explorer”, “MS Word”, and “MS Excel” are registered as regular programs.

  The exclusion list is updated each time a program is installed in the system and stored on the hard disk 22. The contents of the exclusion list are read when the program of the present invention is started.

  After the operation of the program of the present invention, the read exclusion list information is mapped onto the memory 23. It is preferable to always update the files on the hard disk 22 so that the contents are not lost even if the memory information is volatilized due to a sudden machine trouble.

  Also, it is desirable to encrypt the exclusion list file to avoid editing by malware or ransomware.

(User added to exclusion list)
The condition (A) of “Judgment criteria for file encryption operation by ransomware” is that the write start position from HookWriteFile to the write target file is within the head or header range. This condition (A) is a condition for determining whether the monitoring target program rewrites the header of the file. When the monitoring target program rewrites the header of the file, it is determined that the monitoring target program may be ransomware. When the program to be monitored rewrites a part other than the header of the file, it is determined that there is no possibility of ransomware because it is a normal rewriting process.

  Generally, files handled by a computer are classified into two types: “text file (text format)” and “binary file (binary format)”.

  Binary files, for example, files with extensions "doc", "ppt", "exe", "pdf", "jpg", "bmp", etc. usually have header information corresponding to the file type. . Even when the contents of a binary file are edited and changed and overwritten, the head part of the file serving as header information is normally not changed, but the data part is changed. When the binary file header is rewritten, the file cannot be opened properly, and this is not done in normal applications. Therefore, the program that rewrites the file header may be ransomware.

  There are applications that perform processing to rewrite the header at the beginning of the file. In this case, the file type is changed by changing the file extension in accordance with the rewriting of the header. Rewriting the header without changing the file name including the extension is not performed in a normal application. Therefore, a program that rewrites the header of a file without changing the file name may be ransomware.

  On the other hand, a text file, for example, a file with extensions “txt”, “csv” or the like usually does not have header information corresponding to the file type. In the case of a text file, the top part of the file is also a data part. Therefore, even if the text file is rewritten from the beginning, it is difficult to determine whether the text file is encrypted by ransomware or rewritten by a normal application.

  In the program of the present invention, when it is determined that the file is in text format based on the extension of the file, the correspondence is left to the user's determination.

  FIG. 24 shows a warning screen when rewriting of a text format file is detected.

  The warning screen asks "The following process is modifying the text file. How do you handle it?", "Process name: AAATextEditor.exe", "Applicable behavior: Modification of file contents", "Target file : C: \ Users \ test \ Desktop \ Minutes.txt "," Content to be written: "[Minutes] \ n Attendees: Sato ..." ".

  In addition, “* If there is a process or file that you are unfamiliar with the current operation, there is a possibility that the file will be encrypted by ransomware.” And the corresponding process selection buttons “End Process”, “This “Leave warning” and “Add process to exclusion”.

  If the user selects “End Process”, the process “AAATextEditor.exe” is immediately ended. This is when the user determines that the process is ransomware.

  When the user selects “Leave this warning”, the process is continued without terminating the process “AAATextEditor.exe”. This is the case when the user cannot determine whether the process is ransomware or withholds the determination.

  When the user selects “Add Process to Exclude”, the process “AAATextEditor.exe” is added to the “Exclusion List” as shown in FIG. 25 so that the warning for the same process is not performed again. . If the user determines that the process is not ransomware.

  The reference and addition of the exclusion list (white list) from the monitoring target program may be implemented so as to directly access a file on the hard disk 22 or once so as to be accessed via a resident program. Also good.

(Coping behavior)
The coping behavior when the program of the present invention determines that the monitored program is ransomware will be described.

  If the monitoring target program is determined to be ransomware, the process by the monitoring target program is forcibly terminated without writing to the file by WriteFile.

  The process is forcibly terminated in the HookWriteFile function that hooks WriteFile. Generally, this can be realized by using the ExitProcess function, the Exit function, or the like, but any instruction that can terminate the process may be used.

  By forcibly terminating the process, file encryption by ransomware can be prevented. When the process is forcibly terminated, the file is not encrypted, so it is not necessary to back up the file in advance.

  In an environment where inconvenience may be caused by terminating the process immediately, for example, the user is notified in advance that the process is scheduled to be forcibly terminated, and the user is asked to determine whether to terminate the process forcibly. Good. Further, a function of “control of detection accuracy by additional function” described later may be used.

(HookReadFile and HookWriteFile)
FIG. 26 collectively shows an image of the operation by HookReadFile and the operation by HookWriteFile according to the program of the present invention.

  The left part of FIG. 26 shows the process of the program to be monitored, and the right part of FIG. 26 shows the process of the program of the present invention.

  The process of the monitoring target program on the left side of FIG. 26 incorporates HookReadFile and HookWriteFile which are hook functions of the program of the present invention.

  The incorporated HookReadFile notifies (a) the notification source API name, (b) its own process ID, and (c) the ReadFile target file path to the process of the present invention on the right side of FIG. 19 in addition to the normal ReadFile operation. .

  The process of the present invention program on the right side of FIG. 26 receives notifications from the HookReadFile on the left side of FIG. 26 and sequentially records them as notification record data.

  The incorporated HookWriteFile is the same process in the ReadFile notification record data with respect to the process of the program of the present invention on the right side of FIG. 26 based on the process ID of itself (monitored process) and the target file path of WriteFile. Queries whether there is a record of ReadFile of ID and the same target file path. The program of the present invention on the right side of FIG. 26 responds to HookWriteFile whether there is a record of ReadFile with the same process ID and the same target file path.

  The incorporated HookWriteFile further notifies the user when the file to be rewritten is a text file, and shows the user the options of how to deal with it.

  If the user selects to add the monitored process to the exclusion list, the process is added to the exclusion list.

  When the end of the monitored process is selected by the user, the monitored process is forcibly terminated.

(Windows API hook method)
A specific method for hooking the Windows API by the program of the present invention will be described with reference to FIGS.

  All Windows programs are arranged in virtual memory called process space (memory space) when started.

  Each process space has an item called Import Address Table (IAT) as shown in FIG. 27, which is an enlarged view of the state of the malware process space, and IAT contains a list of functions (APIs) used by the program. And a memory address (address) corresponding to this. This is a general mechanism for grasping what function is loaded into which memory when the program runs.

  A method for hook control based on this premise will be described.

  First, as shown in FIG. 28, a hook WriteFile function (HookWriteFile function) is embedded in the process space of the monitoring target program. To inject code into other processes other than yourself, that is, to inject code, use the Windows API called VirtualAllocEx function in the memory space of that process, and allocate a memory area of a certain size to an area that has not been used yet. Secure. The shaded portion on the right side of FIG. 28 is the memory area.

   Next, as shown in FIG. 29, the Windows API called WriteProcessMemory is used to execute the code to be executed in the reserved memory area, here the HookWriteFile function body, and the HookWriteFile function to the IAT in the process space of the monitored program. Write function A for inclusion. This operation is indicated by a thick arrow in FIG. Note that the specific address of the secured memory area can be obtained by checking the return value of VirtualAllocEx.

  Next, as shown in FIG. 30, by calling a Windows API called CreateRemoteThread to execute the written code (function A), the arbitrary code can be executed in the malware process space. This operation is indicated by a thick arrow in FIG.

  Here, when attention is paid only to the process space of the monitoring target program, it is as shown in FIG.

  Next, as shown in FIG. 32, when the function A is executed by CreateRemoteThread, the function A is the address of the regular WriteFile function in the IAT of the process space of the monitored program (the address “0x46700000” in FIG. 32). ) Is rewritten to the address of the HookWriteFile function (the address “0x49000000” in FIG. 32). This completes the hook pre-processing.

  To know which function is expanded to which address, that is, the address corresponding to that function in IAT, pass the function name to the Windows API argument GetProcAddress, and the specified function will be in the process space. It is possible to know the specific address of which address is associated with.

  Next, as shown in FIGS. 33 and 34, it is assumed that the monitoring target program tries to rewrite the file content indicated by the file handle “0x3C0”, for example. In this case, when the WriteFile function is called, the monitored program refers to the IAT in its process space, and as a result, passes the parameter “0x3C0” to the HookWriteFile function instead of the regular WriteFile function.

  Arbitrary processing can be performed inside the HookWriteFile function. Specifically, the content of data originally written using WriteFile is checked or changed in advance. The contents of the HookWriteFile function in the program of the present invention are as described above.

(Control of detection accuracy with additional functions)
When the program of the present invention determines that the monitoring target program is ransomware, the process by the monitoring target program is forcibly terminated to prevent file encryption by the ransomware.

  However, depending on the environment, there may be a problem that the process is immediately terminated. Therefore, an additional function is provided in the program of the present invention to control the detection accuracy of ransomware.

(Control by HookFindNextFile)
HookFindNextFile is a Windows API function that hooks FindNextFile (file search function).

  In addition to HookReadFile that hooks ReadFile (file read function) and HookWriteFile that hooks WriteFile (file write function), HookFindNextFile hooks FindNextFile (file search function) to improve the detection accuracy of ransomware.

  FindFirstFile and FindNextFile are Windows API functions used to find and enumerate files and are typically used in sets.

  FIG. 35 shows operations by FindFirstFile and FindNextFile.

  First, when FindFirstFile is called by specifying the location, the information on the first file at that location is returned from the system, and the information on the first file (AAA.txt) can be obtained.

  Next, when FindNextFile is called, the information (BBB.pdf) of the next file at the location can be acquired from the file handle acquired by FindFirstFile.

  Thereafter, by calling FindNextFile, information on the next file at that location (CCC.txt, DDD.exe,...) Can be acquired sequentially.

  Therefore, if FindFirstFile or FindNextFile is always called when the above-described ransomware is detected by HookReadFile and HookWriteFile, it can be determined that the ransomware is continuously encrypting the file.

  As shown in FIG. 36, first, FindFirstFile is called to obtain information on the first file at a certain location. Subsequently, ReadFile and WriteFile are called and the files are encrypted. Next, call FindNextFile to get information about the next file in that location. Subsequently, ReadFile and WriteFile are called and the files are encrypted. Next, similarly, FindNextFile is called to obtain information about the next file at that location. Subsequently, ReadFile and WriteFile are called and the files are encrypted. Thereafter, the same processing is repeated to continuously encrypt the files at that location.

  In order to detect such continuous encryption processing of files, it is only necessary to hook and monitor FindNextFile. FindFirstFile does not have to be hooked and monitored.

  When called, HookFindNextFile that hooks FindNextFile notifies the following information (a) to (c) to the program of the present invention in addition to the normal operation of FindNextFile.

As the notification means, a high-speed method that does not cause a large delay in the operation of the process, such as inter-process communication, is desirable. Any method may be used as long as the environment can be realized at high speed, such as socket communication or file delivery.
(A) Notification source API name. FindNextFile, the name of the Windows API function to hook.
(B) its own process ID; This is the process ID of the monitored process that calls FindNextFile to hook.
(C) File name that can be acquired from the data buffer specified by the parameter of FindNextFile that is the notification source API. The data buffer stores information about the next file.

  Therefore, on the condition that ransomware is detected by HookReadFile and HookWriteFile, FindNextFile is called before the encryption process, and whether the next file name obtained matches the target file of ReadFile and WriteFile. By confirming whether or not, it is possible to determine that the encryption process is continuously performed on a plurality of files.

  In order to determine the above, for example, HookReadFile, HookWriteFile, and HookNextFile respectively notify (a) a notification source API name, (b) a process ID, and (c) a file path that are notified to the program of the present invention. The data is recorded in advance, and the determination is made based on the notification record data.

  FIG. 37 shows a specific example of the notification record data.

  The notification record data in FIG. 37 includes records of FindNextFile process ID “pid: 1568” and file path “C: \ Users \ user \ Documents \ schedule.xls” in the fourth to sixth lines. Lines 9 and 13 to 15 have a record of ReadFile process ID “pid: 1568” and file path “C: \ Users \ user \ Documents \ schedule.xls”. Lines 10 to 12 and 16 to 16 Line 118 has a record of WriteFile process ID “pid: 1568” and file path “C: \ Users \ user \ Documents \ schedule.xls”.

  The process ID and file path of FindNextFile are the same as the process ID and file path of ReadFile and WriteFile. When it is detected by WriteFile that the header of the file “schedule.xls” has been changed, it is determined that the encryption process is continuously performed on a plurality of files.

In the notification record data shown in FIG.
It is recorded that the same processing is performed on the file "description.doc" in "C: \ Users \ user \ Documents \". When it is detected by WriteFile that the header of the file “description.doc” has been changed, it is determined that the encryption process is continuously performed on a plurality of files in the same folder.

  By setting whether or not to determine whether or not the encryption process is continuously performed on a plurality of files, it is possible to control the accuracy of the detection behavior for the encryption process by the ransomware.

FIG. 38 is a setting screen for enabling the encryption processing for a plurality of files. The expression method of the setting screen in FIG. 38 is an example, and other expression methods may be used. In the setting screen, “Enter encryption processing for multiple files with detection conditions” is displayed after the check button, and “ If not, encryption processing for single files is also included in the detection target ”. The detection condition can be changed when the user checks the check button.

  For example, in a user environment where there is a possibility of performing encryption processing on a single file, if there is no such detection condition, legitimate encryption processing is erroneously detected as ransomware processing. Such erroneous detection and overdetection due to erroneous detection can be prevented from occurring.

(Control by HookMoveFile)
HookMoveFile is a Windows API function that hooks MoveFile (MoveFileA, MoveFileW, MoveFileExA, MoveFileExW) (file move function).

  In addition to HookReadFile hooking ReadFile (file read function) and HookWriteFile hooking WriteFile (file write function), HookMoveFile hooks MoveFile (file move function) to improve ransomware detection accuracy.

  MoveFile is a Windows API function for moving files and changing file names. As shown in FIG. 39, the first argument of MoveFile is the file path (file name) of the movement source, and the second argument is the file path (file name) of the movement destination.

  If the file path excluding the file name of MoveFile's first argument and the second argument is different, the process is "Move File". If the file path excluding the file name of MoveFile is the same as that of the second argument, the process is essentially “change file name”.

  Some ransomware changes the file name to be encrypted after encryption. This is to make it impossible to determine the original file name of the encrypted file, and not only the contents of the file but also the file name are simultaneously encrypted.

  As shown in FIG. 40, such ransomware also performs encryption of the file name by calling MoveFile immediately after the file encryption process is performed. By detecting the flow, the program of the present invention can grasp the encryption behavior of the file name by the ransomware.

  As shown in FIG. 40, FindNextFile is called to obtain information on the next file at that location. Subsequently, CreateFile, ReadFile, and WriteFile are called and the files are encrypted. Next, MoveFile is called to encrypt the file name. In FIG. 40, the file name of the encrypted file “ABS.pdf” is changed to “g1d4fr.vvv” by MoveFile.

  In order to detect such file name encryption processing, MoveFile is hooked and monitored. When called, HookMoveFile that hooks MoveFile notifies the program of the present invention the following information (a) to (c) in addition to the normal operation of MoveFile.

As the notification means, a high-speed method that does not cause a large delay in the operation of the process, such as inter-process communication, is desirable. Any method may be used as long as the environment can be realized at high speed, such as socket communication or file delivery.
(A) Notification source API name. MoveFile, the name of the Windows API function to hook.
(B) its own process ID; This is the process ID of the monitored process that calls MoveFile to hook.
(C) File path specified by the first argument and the second argument of MoveFile which is the notification source API.

  Therefore, on the condition that ransomware is detected by HookReadFile and HookWriteFile, MoveFile is called after the encryption process, and the path of the first argument and the second argument of MoveFile (excluding the file name from the file path) It is possible to determine that the encryption process for the file name is being performed by confirming whether the file paths are the same.

  In order to determine the above, for example, HookReadFile and HookWriteFile respectively notify (a) a notification source API name, (b) a process ID, (c) a file path, and MoveFile respectively notified to the program of the present invention. (A) Notification source API name, (b) Process ID, (c) File path of the first argument, (d) File path of the second argument are recorded in the notification record data. The determination is made based on the notification record data.

  FIG. 41 shows a specific example of the notification record data.

  In the notification record data of FIG. 41, the ReadFile process ID “pid: 1568” and the file path “C: \ Users \ user \ Documents \ schedule.xls” are recorded in the 4th to 6th lines and the 10th to 12th lines. In lines 7-9 and 13-15, there is a record of WriteFile process ID “pid: 1568” and file path “C: \ Users \ user \ Documents \ schedule.xls”. Line 19 contains MoveFile process ID "pid: 1568", first argument file path "C: \ Users \ user \ Documents \ schedule.xls", second argument file path "C: \ Users \ user \ Documents \ g1d4fr6ps There is a record of ".vvv".

  The process ID of MoveFile is the same as the process ID of ReadFile and WriteFile, the file path of the first argument of MoveFile is the same as the file path of ReadFile and WriteFile, the path of the first argument and the second argument of MoveFile The path is the same. If it is detected by WriteFile that the header of the file "schedule.xls" has been changed, "schedule.xls" is encrypted and the file name of "schedule.xls" is also "g1d4fr6ps.vvv" Is determined to be encrypted.

In the notification record data shown in FIG.
It is recorded that the same processing is performed on the file "description.doc" in "C: \ Users \ user \ Documents \". When it is detected that the header of the file “description.doc” has been changed by WriteFile, “description.doc” is encrypted, and the file name of “description.doc” is also “p6dfg7p4.vvv” It is determined that encryption processing has been performed.

  When it is detected that the file name has been changed after detecting the encryption process for the file, the program of the present invention shows the information to the user, and the accuracy of the detection behavior for the encryption process by the ransomware Can be controlled.

FIG. 42 is a setting screen for determining whether or not to warn when a change in file name is detected. The expression method of the setting screen in FIG. 42 is an example, and other expression methods may be used. On the setting screen, “Add“ Change in file name ”to the detection condition” is displayed after the check button and “Do not check” is displayed. If the check box is checked, information about the change in the file name will be displayed at the time of detection, and the action can be selected. " To do. It is possible to set whether or not to warn the user by checking the check button.

  FIG. 43 shows a warning screen when the file content is modified and the file name is modified. Careful users can select how to deal with this information and improve usability, as well as control over-detection due to false positives and false positives.

  The warning screen asks "The following process is changing the text file. How do you handle it?", "Process: AAAA.exe", "Applicable behavior: File content modification, file name modification, "I'm trying to change to" d1g2r.vvv "", "" Target file: C: \ Users \ test \ Document \ BBB.pdf ".

  Furthermore, the corresponding process selection buttons “end process”, “leave this warning”, and “add process to exclusion” are shown.

  If the user selects “End Process”, the process “AAAA.exe” is immediately ended. This is when the user determines that the process is ransomware.

  If the user selects “Leave this warning”, the process continues without terminating the process “AAAA.exe”. This is the case when the user cannot determine whether the process is ransomware or withholds the determination.

  When the user selects “Add Process to Exclude”, the process “AAAA.exe” is added to the “Exclusion List” described above so that the same process is not warned again. If the user determines that the process is not ransomware.

[Second Embodiment]
A program, an information processing apparatus, and an information processing method according to the second embodiment of the present invention will be described with reference to FIGS.

  The first embodiment of the present invention analyzes the behavior of main ransomware, identifies common parts, and detects and protects behaviors that can be determined to be illegal from there. However, file encryption processing is possible without using the analyzed ransomware method.

  Therefore, the inventors of the present application believe that by detecting possible behavior other than the analyzed ransomware, it is possible to reliably detect unknown ransomware and effectively prevent attacks by ransomware. I came up with an embodiment.

  An encryption method assumed by the inventors of the present application will be described. FIG. 44 shows an encryption method assumed by the inventors of the present application.

  When a certain file A is to be encrypted, in the first embodiment of the present invention, the encrypted file is directly overwritten on the original file. However, the encrypted file can be made to exist in the folder in which the original file existed without directly overwriting.

The encryption method of FIG. 44 will be described in the order of step numbers.
(Step 1): The file A is read and encrypted on the memory 23 by ReadFile.
(Step 2): The encrypted data of the file A on the memory 23 is created as a file B at an arbitrary location by WriteFile.
(Step 3-A): The file name of the encrypted file B is changed to the file C by MoveFile.
(Step 3-B): The file name of the encrypted file B is changed to File A by MoveFile, and the file A is overwritten by moving to the folder where the file A exists.
(Step 4): The file C is moved to the folder in which the file A exists by MoveFile.
(Step 5): File A is deleted by DeleteFile.

  After step 5, the state where the file name of the encrypted file A is changed to the file C in the folder in which the file A exists is changed to “state 1”.

  After step 3-B, the state where the encrypted file A exists in the folder in which the file A exists becomes “state 2”.

  FIG. 45 shows a plurality of cases of the encryption method.

  Case 1 of the encryption method is a case in which the process proceeds in the order of Step 1, Step 2, Step 3-A, Step 4, and Step 5 and becomes State 1.

  Case 1 of the encryption method is a case in which the process proceeds in the order of Step 1, Step 2, and Step 3-B and enters State 2.

  In the present embodiment, for example, by detecting Case 1 and Case 2, an assumed behavior other than the analyzed ransomware is detected.

  Note that the behavior to become “state 1” and “state 2” is not limited to case 1 and case 2, but such other cases can be detected by a method similar to the detection method described later. is there.

  Also in this embodiment, the encryption processing by HookReadFile and HookWriteFile in the first embodiment is detected. In this embodiment, in addition to that, HookMoveFile that hooks MoveFile (MoveFileA, MoveFileW, MoveFileExA, MoveFileExW) (file move function) and HookDeleteFile that hooks DeleteFile (file delete function) are used.

  Then, HookReadFile, HookWriteFile, and HookDeleteFile respectively notify (a) the notification source API name, (b) process ID, (c) file path to the program of the present invention, and HookMoveFile notifies the program of the present invention ( a) Notification source API name, (b) Process ID, (c) File path of first argument, (d) File path of second argument are notified. These data notified to the program of the present invention are appropriately recorded in a predetermined list.

(Detection of Case 1)
FIG. 48 shows pre-processing for detection of case 1.

  For the program of the present invention, (a) the notification source API name, (b) the process ID, and (c) the file path notified from HookReadFile are recorded as a list A.

  For the program of the present invention, (a) a notification source API name, (b) a process ID, and (c) a file path notified from HookWriteFile are recorded as a list B.

  For the program of the present invention, a list C shows (a) the notification source API name, (b) the process ID, (c) the file path of the first argument, and (d) the file path of the second argument, which are notified from the HookMoveFile. Record as.

  The detection conditions for Case 1 are as follows.

  Condition 1: DeleteFile is called by a process, and an argument file path (a file to be deleted) is included in the list A. That is, the process ID notified from HookDeleteFile is the same as the process ID notified from HookReadFile, and the file path notified from HookDeleteFile is included in list A.

  A specific example of condition 1 is shown in FIG. As shown in FIG. 47, DeleteFile is called by a certain process, and the file path “C: \ DDD \ CC.doc” of the argument is included in the list A.

  This condition 1 means that a process is trying to delete a file that has been read by ReadFile in the past by DeleteFile.

  Condition 2: The folder path of the argument of DeleteFile (for the file to be deleted) is equal to the folder path of the second argument in list C. That is, the process ID notified from HookDeleteFile is the same as the process ID notified from HookMoveFile, and the path obtained by removing the file name from the file path notified from HookDeleteFile is the file name from the second argument of list C. It is the same as the path except for.

  A specific example of condition 2 is shown in FIG. As shown in FIG. 48, the folder path “C: \ DDD \” of the argument of DeleteFile is equal to the folder path “C: \ DDD \” of the second argument of list C.

  This condition 2 means that the location of a file that a certain process is trying to delete has a record in which the process has designated some file as a destination in the past.

  Condition 3: The file of the first argument of MoveFile is included in the list B. That is, the process ID notified from HookWriteFile is the same as the process ID notified from HookMoveFile, and the same file path as the first argument notified from HookMoveFile.

  A specific example of condition 3 is shown in FIG. As shown in FIG. 49, the first argument file “C: \ XXX \ VV.doc” of MoveFile is included in the list B.

  Condition 3 means that a file written by WriteFile in the past is moved by MoveFile.

  Condition 4: The header of the first argument file of MoveFile that satisfies the above condition 2 is different from the header of the file of the argument of DeleteFile that satisfies the first condition.

  A specific example of condition 4 is shown in FIG. As shown in FIG. 50, the header of the first argument file “C: \ DDD \ CC.doc” of MoveFile is the file “C: \ XXX \ VV.doc” of the argument of DeleteFile that satisfies the first condition. Different from the header.

  The condition 4 is the same as the determination condition for the difference in file header in the first embodiment.

(Detection of Case 2)
FIG. 51 shows pre-processing for detection of case 2.

  For the program of the present invention, (a) the notification source API name, (b) the process ID, and (c) the file path notified from HookReadFile are recorded as a list A.

  For the program of the present invention, (a) a notification source API name, (b) a process ID, and (c) a file path notified from HookWriteFile are recorded as a list B.

  The detection conditions for Case 2 are as follows.

  Condition 1: MoveFile is called by a process, and the file path of the second argument is included in the list A. That is, the process ID notified from HookMoveFile is the same as the process ID notified from HookReadFile, and the file path of the second argument notified from HookMoveFile is included in list A.

  This condition 1 means that this process is trying to overwrite a file that has been read by ReadFile in the past with some file.

  Condition 2: At this time, the file path of the first argument of MoveFile is included in the list B. That is, the process ID notified from HookMoveFile is the same as the process ID notified from HookWriteFile, and the file path of the first argument notified from HookMoveFile is included in list B.

  This condition 2 means that this process is going to move a file that has been written by WriteFile in the past.

  Condition 3: The header of the first argument file of MoveFile is different from the header of the file of the second argument.

  Condition 3 is the same as the condition for determining the difference in file headers in the first embodiment.

[Principle of the Invention (Part 2)]
The principle (part 2) of the present invention will be described with reference to FIGS.

(Ransomware analysis)
The inventors of the present application further analyzed other ransomware that has been reported to be damaged domestically and internationally.

  As described in the principle of the invention (part 1), when a normal ransomware encrypts a file, Windows APIs such as ReadFile and WriteFile are used when reading and writing the file. Therefore, in the first embodiment of the present invention and the second embodiment of the present invention based on the principle (part 1) of the invention, when a file is operated using a file read / write function, that is, ReadFile or WriteFile, Ransomware is detected based on whether the header of the file has been rewritten.

However, ransomware includes a type of ransomware that performs file operations using a mechanism called file mapping when a file is encrypted. Such ransomware does not use ReadFile and WriteFile, which are file read / write functions. For this reason, it is difficult to detect such ransomware in the first embodiment of the present invention and the second embodiment of the present invention based on the principle (part 1) of the invention.
(A) Difference between general file operation and file operation by file mapping The difference between a general file operation and a file operation by file mapping will be described with reference to FIG.

  As shown in FIG. 52, the actual file is stored in the hard disk 22. In each file read / write process in general file operations, a series of processes such as preparing a buffer (not shown) in the memory 23, reading the file, and writing the edited data back to the file are performed.

  File mapping is a technique that enables an operating system (Windows OS) to treat a file like memory data.

  In the file operation by file mapping, as shown in FIG. 52, the entire real file stored in the hard disk 22 is expanded in the memory 23 as a virtual file (file mapping object). When the file contents are rewritten in the file operation by the file mapping, the contents are rewritten with respect to the virtual file expanded in the memory 23 each time. The result of changing the contents of the file is reflected in the actual file on the hard disk 22 at the final stage of the series of processes.

  As shown in FIG. 52, the actual file stored in the hard disk 22 can be accessed from the process, and the virtual file expanded in the memory 23 can be accessed from the process.

  When performing file operations, rewriting a virtual file developed in the memory 23 is overwhelmingly faster than rewriting a real file stored in the hard disk 22.

Therefore, in the file operation by the file mapping, it is not necessary to perform the read process and the write process for the actual file every time the contents are changed as in the general file operation. Therefore, the file operation by file mapping can rewrite the contents of the file at a higher speed.
(B) Analysis of Ransomware Spora (File operation)
As a result of investigation by the inventors of the present application, it was found that “Spora” that appeared in early 2017 in ransomware is performing file operations by file mapping.

As a result of analyzing the ransomware Spora by the inventors of the present application, the flow of file operations during file encryption was found. FIG. 53 shows a flow of file operation when encrypting a file by ransomware Spora.
(Step 1): Use CreateFile to open the actual file to be encrypted.
(Step 2): Create a virtual file (file mapping object) by CreateFileMapping.
(Step 3): Map to the memory address space of the process by MapViewOfFile.
(Step 4): The file mapping object is encrypted on the memory.
(Step 5): Unmap the file mapping object by UnmapViewOfFile.
(Step 6): The file handle is closed by CloseHandle.

Further, the timing at which a change to the file mapping object, which is a virtual file on the memory 23, is reflected on the actual file on the hard disk 22 was analyzed. As a result, it was found that encryption is reflected in the actual file on the hard disk 22 at the next timings (1) to (5).
(1) Timing when UnmapViewOfFile is called.
(2) Timing when UnmapViewOfFileEx is called.
(3) Timing when FlushViewOfFile is called.
(4) Timing when CloseHandle is called.
(5) The timing when the handle of the file mapping object is closed except for the above (1) to (4).

  In a general correct processing procedure, after unmapping a file mapping object by (1) UnmapViewOfFile or (2) UnmapViewOfFileEx, the file object is closed by (4) CloseHandle. Note that (3) FlushViewOfFile may write a specified range of data in the mapped file to the disk.

  However, even if the functions (1) to (4) are not called, the encryption is reflected in the actual file on the hard disk 22 even if the handle of the file mapping object is closed by some trigger such as ending the process. Is done.

  FIG. 54 shows the relationship between the file operation by the ransomware Spora and the hardware.

  First, the process opens an actual file to be encrypted on the hardware 22 by CreateFile (step 1).

  Next, as shown in FIG. 54A, the process creates a virtual file (file mapping object) of a real file by CreateFileMapping (step 2), and the process stores the memory of the process on the memory 23 by MapViewOfFile. A virtual file is mapped to the address space (step 3).

  As shown in FIG. 54A, in a general file operation, an access to an actual file on the hard disk 22 uses ReadFile and WriteFile which are file read / write functions. However, ReadFile and WriteFile are not used in file encryption operations by ransomware Spora.

  Next, the process encrypts the file mapping object on the memory 23 (step 4).

  Next, as shown in FIG. 54B, the process unmaps the file mapping object using UnmapViewOfFile (step 5), and the process closes the file handle using CloseHandle (step 6). As a result, the change to the encrypted virtual file (file mapping object) on the memory 23 is reflected in the actual file on the hard disk 22.

  The timing at which the change to the virtual file (file mapping object) on the memory 23 is reflected in the actual file on the hard disk 22 is the timing at which UnmapViewOfFile is called, the timing at which CloseHandle is called, and UnmapViewOfFileEx. There is a timing at which the file mapping object handle is closed, other than the above timing when FlushViewOfFile is called, and other times.

  In the present specification, “when mapping” means when a virtual file (file mapping object) is mapped into the memory address space of the process. For example, when a real file to be encrypted is opened by CreateFile, a virtual file (file mapping object) is created by CreateFileMapping, and mapping is performed in the memory address space of the process by MapViewOfFile.

In the present specification, “when unmapping” refers to a time when a change to a file mapping object, which is a virtual file on the memory 23, is reflected in an actual file on the hard disk 22. For example, it is the timing of the following timings (1) to (5).
(1) Timing when UnmapViewOfFile is called.
(2) Timing when UnmapViewOfFileEx is called.
(3) Timing when FlushViewOfFile is called.
(4) Timing when CloseHandle is called.
(5) The timing when the handle of the file mapping object is closed except for the above (1) to (4).

Even if the functions (1) to (4) are not called, the encryption is reflected in the actual file on the hard disk 22 even when the handle of the file mapping object is closed by some trigger such as termination of the process. .
(About changing file contents)
The difference between the change of the file by the ransomware and the change of the file by the normal application is noticeable in the file having the header information. When a normal application rewrites a file, the file header information is not changed as it is, and the data in the middle part of the file is overwhelmingly rewritten. On the other hand, when the ransomware encrypts the file, the file header information is rewritten.

  Therefore, by comparing the head portions of the files, it is possible to determine an operation that is highly likely to be ransomware encryption and an operation that is not otherwise performed by a normal application.

  In order to detect ransomware over a wider area and prevent false detection, it is essential to monitor “changes in the file structure to an inappropriate state” rather than monitoring only the beginning of the file. It is a serious request.

  This is because the purpose of the ransomware creator is to obtain a ransom from the user. If the user tries to open the file and is unable to open the file, the user will recognize the ransomware infection and attempt to pay the ransomware creator a ransom. The same applies when the contents of the file are rewritten significantly.

Examples of the “change of the file structure to an inappropriate state” that motivate the user to pay the ransom (ransom) include the following modes.
(I) Change of header information When header information is changed, it cannot be opened by an application. For example, in a file with the extension “.pdf”, if the file is not in the PDF format, the file cannot be opened by an application that supports the PDF format.

  In many files having header information, the header information of the file is at the beginning of the file. However, some file types do not have file header information at the beginning of the file. It is not possible to monitor changes in the header information of various types of files only by monitoring the beginning of the file.

  The position of the header information is determined for each file type. The header information change is monitored by monitoring the position of the header information determined according to the file type.

The position of the header information with respect to the file type can be known from the public information. As public information, there is information that discloses a fixed value in a header called a magic number of a file, and information that discloses an RFC definition for each format.
・ Magic number (programming)
https://en.wikipedia.org/wiki/Magic_number_(programming)
・ Windows Image Media Types
https://tools.ietf.org/html/rfc7903#section-1.2
For example, the magic header of the file with the extension “GIF” (the first data of the file) is “47 49 46 38 39 61” or “47 49 46 38 37 61”. If it is, it can be determined as an encryption operation.

For header information of files with extensions that do not exist in the public information, a fixed size from the beginning of the file is regarded as header information and monitored. Further, this monitoring method may be used in combination with other monitoring methods.
(Ii) Change of footer information A general file has a format of “header + body”, but there is a file format of “header + body + footer”. In such a file, when the footer information is changed, the file may not be opened by the application.
(Iii) Changing body information Depending on the type of file, certain rules may be established for the body structure.

  For example, there is a file in which the body is divided into four data portions, and a rule is defined that a plurality of bytes of 0x00 (null character) are continued at the end of each data portion. In the case of such a file, if the end of each data part is encrypted and is not 0x00 (null character), it cannot be opened by an application.

  In addition, there is a file in which rules such as the number of data parts existing in the body, the size of each data part, and the start position of each data part are defined on the header. For such files, if changes that deviate from this rule are made to the body, they cannot be opened by the application.

In addition, there is a file in which a range of values (binary values) taken by the body is defined. For such files, if changes are made to the body that deviate from the specified range, the application cannot open it.
(Detection conditions for Ransomware Spora)
Based on the analysis of the ransomware Spora, the present inventors have come up with the following detection conditions that can effectively detect the ransomware Spora.
(A) Condition A: There is a change to an inappropriate state of the file structure.

  Condition A is that the file structure of the file is rewritten to an inappropriate state.

The change to an inappropriate state of the file structure includes, for example, a change in header information, a change in footer information, and a change in body information.
(I) Change of header information Condition A in this case is that the header information of the same file is rewritten.

  In ransomware using file mapping, a real file on the hard disk 22 is expanded as a virtual file on the memory 23. Therefore, the condition A is either the following condition A1 or condition A2.

  Condition A1: The header information of the actual file before the file operation and the header information of the actual file at a predetermined timing after the file operation are compared and rewritten.

  Condition A2: The header information of the real file before the file operation and the header information of the virtual file at a predetermined timing after the file operation are compared and rewritten.

  The predetermined timing after the file operation is a timing at which a change to the file mapping object that is a virtual file on the memory 23 is reflected in the actual file on the hard disk 22. Specifically, it is the timing of (1) to (5) described above.

  In the case of the timing of (5) when the handle of the file mapping object is closed, it may be difficult to capture the timing.

  Actually, in many files having header information, the header information of the file is at the head of the file.

  When the header information is at the head portion of the file, the condition A is that the data at the head portion is rewritten. In this case, the condition A is either the following condition A1 or condition A2.

  Condition A1: The data at the beginning of the real file before the file operation and the data at the beginning of the real file at a predetermined timing after the file operation are compared and rewritten.

Condition A2: The data at the beginning of the real file before the file operation and the data at the beginning of the virtual file at a predetermined timing after the file operation are compared and rewritten.
(Ii) Change of footer information Condition A in this case is that the footer information of the same file is rewritten.

  The condition A is either the following condition A1 or condition A2.

  Condition A1: The footer information of the actual file before the file operation and the footer information of the actual file at a predetermined timing after the file operation are compared and rewritten.

Condition A2: The footer information of the real file before the file operation and the footer information of the virtual file at a predetermined timing after the file operation are compared and rewritten.
(Iii) Change of body information Condition A in this case is that the data of the body of the same file is rewritten.

  The condition A is either the following condition A1 or condition A2.

  Condition A1: The data of the body of the actual file before the file operation is compared with the data of the body of the actual file at a predetermined timing after the file operation.

Condition A2: The actual file body data before the file operation and the virtual file body data at the predetermined timing after the file operation are compared and rewritten.
(B) Condition B: There is a continuous operation of the file mapping object.

  When file mapping is used, it is necessary to read the API called CreateFileMapping and the API called MapViewOfFile once for each file. Therefore, when continuous file mapping occurs, an API called CreateFileMapping and an API called MapViewOfFile are read twice or more.

  Therefore, the condition B is specifically that an API called CreateFileMapping and an API called MapViewOfFile are read out a plurality of times.

  The provision of the condition B has the following significance. Ideally, it is desirable that the encryption of the first file can be detected by the condition A, but even if this is difficult, the encryption operation of the file can be reliably detected by the detection of the condition B.

[Third Embodiment]
A program, an information processing apparatus, and an information processing method according to the third embodiment of the present invention will be described with reference to FIGS.

(Outline of this embodiment)
The outline of this embodiment will be described with reference to FIGS. 55 and 56. FIG.

  In the present embodiment, all behaviors of a program having a behavior of accessing user data stored in the hard disk 22 are detection targets.

  The CPU 21 executes a process of OS data on the memory 23, accesses a program stored in the hard disk 22, reads the program (FIG. 2C), and stores the program stored in the hard disk 22 in the memory 23. Before being loaded and expanded as a process on the memory 23 (FIG. 3A), the process of the program of the present invention is made resident in the memory 23 (FIG. 55A).

  The program of the present invention may be executed at any time before the ransomware is in danger of being introduced and may be made resident as a process in the memory 23.

  For example, it is started as a startup program when the computer is started. An operating system (Windows OS) has a mechanism in which a “start-up program” can be registered as a program that is executed when the PC is started. In the present embodiment, the program of the present invention is registered as a startup program using the mechanism. As a result, the program of the present invention is placed on the memory 23 immediately after the PC is started.

  In addition, as a method of starting a program when the PC is started, there is a method of using a registry or a service mechanism, but any method may be used.

  As a result, the computer can always be protected from ransomware immediately after the PC is started.

  As shown in FIG. 55A, the program of the present invention interrupts between an operation in which the program stored in the hard disk 22 is loaded into the memory 23 and an operation in which the CPU 21 executes the program. By hooking the operation based on the program by the CPU 21, the behavior of the program is placed under the monitoring of the program of the present invention immediately before the program is executed.

  Thereby, thereafter, all behaviors of the monitoring target program can be grasped immediately before execution of the program of the present invention. As necessary, functions can be added to or changed in the processing of the monitoring target program.

  The program of the present invention causes the computer to function as a determination unit that determines that the monitoring target program is ransomware.

  The computer program causes the computer to execute a determination procedure for determining that the monitoring target program is ransomware.

  When the behavior of the monitoring target program is determined to be ransomware-specific behavior by the determination unit or determination procedure, as shown in FIG. Block the access just before trying to access the file. In this way, attacks by unknown ransomware are blocked to prevent file encryption.

(Three functions of the program of the present invention)
The program of the present invention has three functions. Three functions of the program of the present invention will be described with reference to FIG.

  The first function is a function for hooking a Windows API used by a monitoring target process that is a program that is currently operating or a program that is activated later. As shown in FIG. 56, the present invention program hooks the Windows API used by the currently running process, that is, notepad.exe, WINWORD.exe, calc.exe, Ramsomware.exe, cmd.exe,. To do.

  The second function is a function for recording the behavior of the process to be monitored by the hooked Windows API.

  The third function is a function for determining whether or not the ransomware is based on the behavior recorded by the second function.

  The first function is a function of the resident program of the present invention, and the second function and the third function are functions of the program of the present invention incorporated in the monitored process.

  The resident program of the present invention may have the first function and the third function, and the program of the present invention incorporated in the process to be monitored may have the second function. In this case, the program of the present invention incorporated in the process to be monitored notifies the resident program of the resident invention of the behavior recorded by the second function, and the resident program of the ransom is ransom by the third function. Whether it is wear.

(First function: Function to hook API used by monitored process)
The program of the present invention hooks an API that is a behavior obtained from the analysis result of the ransomware and an API having a function equivalent to this in the monitored process. The hook target API in this embodiment is as follows.

CreateFileMapping
MapViewOfFile / MapViewOfFileEx
UnmapViewOfFile / UnmapViewOfFileEx
FlushViewOfFile
CloseHandle
A specific method for hooking the API will be described later.

  The monitored process is a program that is currently operating and a program that is subsequently started. Programs listed in the exclusion list described later are excluded from the monitored processes. Even if they are not in the exclusion list, programs whose file origins are clear due to digital signatures, etc., and programs whose safety has been confirmed can be excluded from monitored processes.

(Second function: Function to record the behavior of monitored process by hooked API)
The program of the present invention records the behavior of the monitored process by the API hooked by the first function.

  In order to record the behavior of the monitoring target process, API hook functions of CreateFileMapping and MapViewOfFile / MapViewOfFileEx are used among the APIs listed in the first function.

(HookCreateFileMapping function)
The HookCreateFileMapping function is a function that hooks an API called CreateFileMapping.

  CreateFileMapping is an API that creates or opens a named or unnamed file mapping object for a specified file when reading and writing the file using file mapping.

Microsoft reference
https://msdn.microsoft.com/en-us/library/cc430039.aspx
Describes the CreateFileMapping. An excerpt is shown in FIG.

  The HookCreateFileMapping function, which is a hook function of CreateFileMapping, has a function of recording information captured by the hook and information acquired by calling normal CreateFileMapping.

The information recorded by the HookCreateFileMapping function is as follows: Note that the file specified by CreateFileMapping is referred to as an “encryption target file” for convenience of explanation of encryption.
(A) Encrypted file handle
File handle (hFile) specified when the CreateFileMapping API is called.
(B) File path to be encrypted File path acquired based on the file handle. The file path can be obtained from the file handle (hFile).
(C) Handle of file mapping object
The return value obtained by calling CreateFileMapping.

It can be obtained by calling the original CreateFileMapping before the hook in the hook function (HookCreateFileMapping function).
(D) Header data before encryption of the encryption target file Header data acquired based on the file handle. The file handle (hFile) can be obtained by reading the file header data using an API such as ReadFile. As shown in FIG. 58, based on the file handle (hFile), the header data before encryption of the file to be encrypted is read from the hard disk 22 using the API of ReadFile, for example.

  Information recorded by the HookCreateFileMapping function in this manner is recorded on the memory 23 in a list format as shown in FIG. 59, for example. Hereinafter, this list is referred to as a “memory mapped list”.

In FIG. 59, the handle of the encryption target file is “0xABC”, the encryption target file path is “C: \ test.pdf”, the handle of the file mapping object is “0xABCD”, and the encryption target file is This indicates that the header data before encryption is “25 50 44 46 2D”.
(E) Real file backup function
The HookCreateFileMapping function also has a function of backing up the actual file indicated by the handle of the encryption target file.

  Specifically, this is a function for determining a file path from the encryption target file handle specified as the first argument of the HookCreateFileMapping function and storing the file in another location on the hard disk 22. The storage location can be anywhere.

  When encryption by ransomware is detected, the unencrypted file is copied and restored from this backup.

  The backup is a temporary file to the last, and when encryption does not occur, the disk is squeezed unnecessarily, so this temporary file is deleted as appropriate.

  When storing, it is desirable to encrypt file names and file contents including extensions. It is also desirable to take measures such as storing in a folder that cannot be written by other than a specific program. This is to prevent backup files from being replaced or deleted by an attacker.

  FIG. 60 shows a specific example of the flow of file restoration after encryption detection from file backup at the time of file mapping.

  When the CreateFileMapping function is called (step 1), the file path (C: \ users \ test \ Desktop \ test.doc) is acquired from the encryption target file handle (0x1A) specified in the first argument of the HookCreateFileMapping function ( Step 2). The file (test.doc) calculated from the acquired file path (C: \ users \ test \ Desktop \ test.doc) is stored as an encrypted file (91B4083010E141872685) in another location (step 3).

  After that, when the ransomware encrypted file (C: \ users \ test \ Desktop \ test.doc.encrypted) is detected (step 4), the backup file (91B4083010E141872685) is decrypted and the file (C: (\ users \ test \ Desktop \ test.doc) is restored (step 5).

  In addition, it is necessary to delete the backed up files regularly so as not to compress the disk. The frequency of deletion is arbitrary, but delete files that have passed a certain period of time, delete old files when the number of backup files exceeds a certain number, or start old files when the remaining disk capacity falls below a certain amount. It is necessary to perform processing that does not exhaust the disk resources, such as deleting.

(HookCreateFile function)
The HookCreateFile function is a function that hooks an API called CreateFile.

  In FIG. 60, a backup file is created by the HookCreateFileMapping function that hooks CreateFileMapping. However, a backup cannot be created if the file is opened in exclusive mode.

  For this reason, the backup function is preferably backed up before being opened in the exclusive mode by the HookCreateFile function that hooks CreateFile called before the CreateFileMapping function.

  CreateFile is a function that creates an object to access an object such as a file or returns an available handle. By calling this function, you can get a handle for reading from and writing to the specified file.

Microsoft reference
https://msdn.microsoft.com/en-us/library/cc429198.aspx
Contains a description of CreateFile. An excerpt is shown in FIG.

  Add the following functions to the HookCreateFile function, which is a hook function of CreateFile.

  When the file name specified in the parameter at the time of calling exists, this is a function for backing up the file, that is, a function for copying to another location.

  In order to determine which process the file name of the backup file is encrypted, it is desirable to embed, for example, a process ID, a process name, or the like.

  Since CreateFile is a function that is called frequently regardless of the encryption operation, there is a risk of squeezing the disk space if everything is backed up. For this reason, the backup target may be set only when conditions such as specifying the write authority to acquire a handle or specifying the exclusive mode to acquire a handle are satisfied.

  The backup is only a temporary file and should be deleted so as not to squeeze the disk if encryption does not occur.

  For example, it may be stored in% temp% (eg C: \ Users \ test \ AppData \ Local \ Temp), which is a temporary folder for each user that is used as a temporary area in the operating system (Windows OS). .

  In addition, it is necessary to delete the backed up files regularly so as not to compress the disk. The frequency of deletion is arbitrary, but delete files that have passed a certain period of time, delete old files when the number of backup files exceeds a certain number, or start old files when the remaining disk capacity falls below a certain amount. It is necessary to perform processing that does not exhaust the disk resources, such as deleting.

(HookMapViewOfFile function / HookMapViewOfFileEx function)
The HookMapViewOfFile function is a function that hooks an API called MapViewOfFile. The HookMapViewOfFileEx function is a function that hooks an API called MapViewOfFileEx.

  MapViewOfFile and MapViewOfFileEx are functions that map a view of a file to a process address space by specifying a mapping object created by CreateFileMapping. By calling this function, the address associated with the data of the read file can be acquired.

Microsoft reference
https://msdn.microsoft.com/en-us/library/cc430198.aspx
Describes the MapViewOfFile. An excerpt is shown in FIG.

Microsoft reference
https://msdn.microsoft.com/en-us/library/cc430178.aspx
Describes the MapViewOfFileEx. An excerpt is shown in FIG.

  The HookMapViewOfFile function and HookMapViewOfFileEx function, which are hook functions of MapViewOfFile and MapViewOfFileEx, have the following functions.

  This function checks whether the file mapping object handle (hFileMappingObject) specified in the parameter at the time of calling exists in the memory-mapped list, and if it exists, adds the start address of the map to that line.

  The map start address is the “mapped view start address” of the return value obtained by calling MapViewOfFile / MapViewOfFileEx. The “mapped view start address” can be obtained by calling the original MapViewOfFile / MapViewOfFileEx before hooking in the HookMapViewOfFile function / HookMapViewOfFileEx function.

  In the specific example shown in FIG. 63, since the file mapping object handle “0xABCD” specified as the parameter at the time of calling exists in the memory mapped list, the map start address “0x201000” is added to that line.

(Memory mapped list)
As described above, the memory-mapped list shown in FIG. 64 is generated by the HookCreateFileMapping function, HookMapViewOfFile function / HookMapViewOfFileEx function.

  “Handle of encryption target file”, “File path of encryption target”, “Handle of file mapping object”, “Header data before encryption” of memory mapped list are inserted by HookCreateFileMapping function, and “Map start address” is HookMapViewOfFile Inserted by function / HookMapViewOfFileEx function.

  Each time the HookCreateFileMapping function is called, new “handle of encryption target file”, “file path of encryption target”, “handle of file mapping object”, and “header data before encryption” are added to the memory mapped list. It is not necessary to add what is already recorded in the list. Each time the HookMapViewOfFile function / HookMapViewOfFileEx function is called, a new “map start address” is added.

  FIG. 64 shows an example of a memory-mapped list recorded in “(third function (part 2): when the map is not explicitly closed / reflected)” to be described later.

  Specifically, since the second file “2.pdf” is mapped in the process of sequentially encrypting the files in the “C: \ document \” folder, the file “1.pdf” is not encrypted. It shows a situation in which the header data is compared with the encrypted (current) header data.

  If the header data of the file “1.pdf” is different, it is determined that the mapping process is intended for encryption.

  The information in the memory mapped list shown in FIG. 64 is cleared when one monitored process ends.

  When the program of the present invention is operated as a resident program, the information in the memory mapped list is not cleared even if one monitored process is terminated. Therefore, by reusing the handle value of the operating system, there is a possibility of erroneously detecting that the handle value coincides accidentally even though the handle is different. In order to prevent such erroneous detection, it is desirable to periodically clear the memory mapped list. You may enable it to set the clearance which a user clears. It is also desirable to clear it when the operating system is terminated or restarted.

  In ransomware encryption, there is often a flow of processing files one by one. Therefore, in mapping encryption, the basic flow is to repeat “map”, “encryption”, and “unmap” alternately. Become. If this basic flow is supported, the memory mapped list does not need to be large.

  However, if you perform a process of mapping many files at once, then encrypting many files, and then unmapping many files at once, the memory-mapped list will contain many files. It is necessary to provide this area.

(Third function: a function for determining whether or not the ransomware is using a record)
In the program according to the present invention, the third function determines whether the monitored process is ransomware based on the behavior recorded by the second function. There are cases where the monitoring target process explicitly performs the map closing / reflecting process, and there are cases where the map closing / reflecting process is not explicitly performed, and the process is performed assuming each case.

(Third function (part 1): When the map is closed / reflected explicitly)
In order to record the behavior of the monitoring target process, the hook function of the following API is used among the hook target APIs listed in the first function.

UnmapViewOfFile / UnmapViewOfFileEx
FlushViewOfFile
CloseHandle
The UnmapViewOfFile function and the UnmapViewOfFileEx function are functions for releasing (unmapping) the mapped memory (hereinafter, the memory in this state is referred to as “mapped memory”). By unmapping, the data in the mapped memory is reflected in the file, so that the operation is substantially written to the actual file. If the monitored process is ransomware, the actual file is encrypted.

  The FlushViewOfFile function is a function that reflects the data on the mapped memory in the actual file by calling this function, although the mapped state (mapped memory) is not released (unmapped).

  The CloseHandle function is a more widely used API. In file mapping, it is called when the mapped virtual file is closed after the mapped virtual file has been written to the real file. Therefore, in a normal program, before calling CloseHandle, the virtual file is unmapped by the UnmapViewOfFile function or the UnmapViewOfFileEx function. However, when CloseHandle is called without calling the UnmapViewOfFile function or UnmapViewOfFileEx function, the data in the mapped memory is reflected in the actual file. Therefore, the CloseHandle function is also an API that should be monitored as a write timing to an actual file, like the UnmapViewOfFile function, UnmapViewOfFileEx function, and FlushViewOfFile function.

(HookUnmapViewOfFile function / HookUnmapViewOfFileEx function)
The HookUnmapViewOfFile function is a function that hooks an API called UnmapViewOfFile. The HookUnmapViewOfFileEx function is a function that hooks an API called UnmapViewOfFileEx.

  UnmapViewOfFile and UnmapViewOfFileEx are functions that cancel (unmap) the mapped state (mapped memory).

Microsoft reference
https://msdn.microsoft.com/en-us/library/cc430200.aspx
Describes the UnmapViewOfFile. An excerpt is shown in FIG.

Microsoft reference
https://msdn.microsoft.com/en-us/library/windows/desktop/mt670639(v=vs.85).aspx
Describes the description of UnmapViewOfFileEx. An excerpt is shown in FIG.

In addition to the normal UnmapViewOfFile / UnmapViewOfFileEx operations, the following functions are added to the HookUnmapViewOfFile and HookUnmapViewOfFileEx functions that are hook functions of UnmapViewOfFile and UnmapViewOfFileEx.
(A) A function that checks whether the mapped memory (lpBaseAddress) specified in the parameter at the time of calling exists in the memory mapped list, and if it exists, obtains “header data before encryption” of that line .
(B) Check whether the mapped memory (lpBaseAddress) specified in the parameter at the time of calling exists in the memory mapped list, and if it exists, “encrypted header data” mapped to the position of lpBaseAddress A function to acquire (first data on mapped memory).

When UnmapViewOfFile is called, it is considered that MapViewOfFile has already been called and that it is desired to cancel the mapping because the mapped memory is finished and the contents of the mapped memory are reflected in the file. Therefore, the head data of the mapped memory at this time can be regarded as header data after file encryption.
(C) Compare the above-mentioned “header data before encryption” and “header data after encryption”, and if there is a difference, it is determined that the file encryption operation is performed by ransomware, and the process ends. Function to let you.

  A specific example of these functions is shown in FIG. In the example shown in FIG. 66, the “header data before encryption” of the handle “0xABC” of the encryption target file is “25 50 44 46 2D”, and the “start address (lpBaseAddress)” of the parameter of HookUnMapViewOfFileFile / HookUnMapViewOfFile “0x201000” is specified. The data “50 4B 03 04 14” at the address “0x201000” on the memory 23 is “encrypted header data”. In the example shown in FIG. 66, the header data “25 50 44 46 2D” before encryption is different from the header data “50 4B 03 04 14” after encryption, so that it is a file encryption operation by ransomware. Determine and terminate the process to be monitored.

(HookFlushViewOfFile function)
The HookFlushViewOfFile function is a function that hooks an API called FlushViewOfFile.

  FlushViewOfFile is a function that writes the specified range of data in the mapped file view to disk.

Microsoft reference
https://msdn.microsoft.com/en-us/library/cc430048.aspx
Describes the FlushViewOfFile. An excerpt is shown in FIG.

  Since FlushViewOfFile has a map start address (lpBaseAddress) in the call parameter, similarly to UnmapViewOfFile / UnmapViewOfFileEx, encryption can be detected in the same manner as HookUnmapViewOfFile / HookUnmapViewOfFileEx.

In addition to the normal FlushViewOfFile operation, the following functions are added to the HookFlushViewOfFile function that is a hook function of FlushViewOfFile.
(A) A function that checks whether the mapped memory (lpBaseAddress) specified in the parameter at the time of calling exists in the memory mapped list, and if it exists, obtains “header data before encryption” of that line .
(B) Check whether the mapped memory (lpBaseAddress) specified in the parameter at the time of calling exists in the memory mapped list, and if it exists, “encrypted header data” mapped to the position of lpBaseAddress A function to acquire (first data on mapped memory).
(C) Compare the above-mentioned “header data before encryption” and “header data after encryption”, and if there is a difference, it is determined that the file encryption operation is performed by ransomware, and the process ends. Function to let you.

(HookCloseHandle function)
The HookCloseHandle function is a function that hooks an API called CloseHandle.

  CloseHandle is an API that is called when a file is closed.

Microsoft reference
https://msdn.microsoft.com/en-us/library/cc429605.aspx
Describes the CloseHandle. An excerpt is shown in FIG.

  When using file mapping, it is generally unmapped before calling CloseHandle. Therefore, unmap can generally be detected by HookUnmapViewOfFile / HookUnmapViewOfFileEx. However, it is possible to immediately close the file without using HookUnmapViewOfFile / HookUnmapViewOfFileEx that intentionally unmaps, and in this case, the contents of the mapped memory may be reflected in the actual file. It is desirable to detect as a trigger.

  In addition to the normal CloseHandle operation, the following functions are added to the HookCloseHandle function, which is a hook function of CloseHandle.

  Also in the HookCloseHandle function, the basic concept of what should be performed is the same as in the case of the HookUnmapViewOfFile / HookUnmapViewOfFileEx function. Using the memory-mapped list, the previous file state (header data before encryption) and the header data after encryption at the timing when HookCloseHandle is called are acquired, and these header data are compared.

  The difference from the case of the HookUnmapViewOfFile / HookUnmapViewOfFileEx function is how the memory mapped list is traced until the header data is acquired. The method of tracing is shown in FIGS.

  There is no “map start address” in the CloseHandle function parameter, only the file handle. Therefore, in order to obtain the state of the previous file (header data before encryption), as shown in FIG. 69, search for “handle of encryption target file” in the memory-mapped list and specify it as a parameter. Get the value of the “header data before encryption” column in the row that matches the value of the file handle hObject.

  However, the value of “file handle” may be reused by the operating system (Windows OS). Therefore, in order to avoid false detection due to matching of handles, “file path” is obtained from “file handle (hObject)”, and in addition to matching of “file handle”, the obtained “file path” and “file to be encrypted” It may be a condition that the values in the “path” column match.

  As for obtaining header data after encryption, as shown in FIG. 70, a method of reading head data (header data) from an actual file on the hard disk 22 using a ReadFile function or the like from a file handle (hObject), or before hooking The original CloseHandle is called, the closed file is reopened, and the head data (header data) is read from the actual file on the hard disk 22.

  Given the processing overhead, using the file handle to get the top data seems to give better performance.

(Summary of the third function)
The operation when the map close / reflect processing is explicitly performed will be described in time series with reference to FIG.

  First, in step 1, a new line is added to the memory-mapped list by HookCreateFileMapping. In the new line, the handle of the encryption target file, the encryption target file path, the handle of the file mapping object, and the header data before encryption of the encryption target file are entered.

  In FIG. 71, the encryption target file handle is “0xABC”, the encryption target file path is “C: \ test.pdf”, the file mapping object handle is “0xABCD”, and the encryption target file is The header data before encryption is “25 50 44 46 2D”.

  Next, in step 2, the start address of the map is entered in the memory mapped list by HookMapViewOfFile / HookMapViewOfFileEx.

  In FIG. 71, since the file mapping object handle “0xABCD” specified as the parameter at the time of calling exists in the memory mapped list, the map start address “0x201000” is added to the line.

  Next, in step 3, if the monitored process is ransomware, the data in the mapped memory is encrypted.

  Next, in step 4, by using HookUnmapViewOfFile / HookUnmapViewOfFileEx or HookFlushViewOfFile, first, a search is made from the “map start address” column that matches the address specified in the parameter when calling UnmapViewOfFile / UnmapViewOfFileEx or HookFlushViewOfFile. (Step 4-1). Next, if there is a matching line, the header data of that line (before encryption) is compared with the current header data (after encryption) acquired from the mapped memory, and if there is a difference, it is encrypted. Judge that In this way, it is determined whether or not the process to be monitored is ransomware (step 4-2).

  In FIG. 71, the header data “25 50 44 46 2D” before encryption of the memory mapped list is acquired from the parameter “0xABCD” at the time of calling, and the address “0x201000” specified by the parameter “0xABCD” at the time of calling is acquired. To obtain the current header data (after encryption) “50 4B 03 04 14”. Since there is a difference when these are compared, it is determined that the process to be monitored is ransomware.

(Ransomware detection process (1))
Details of the ransomware detection process (part 1) will be described with reference to the flowchart of FIG.

  This is ransomware detection processing when HookUnmapViewOfFile / HookUnmapViewOfFileEx or HookFlushViewOfFile is used.

  First, it is determined whether or not the address specified in the parameter “lpBaseAddress” at the time of calling UnmapViewOfFile / UnmapViewOfFileEx or HookFlushViewOfFile exists in the memory mapped list (step S11).

  If the address does not exist in the memory mapped list, the ransomware detection process is immediately terminated.

  If the address exists in the memory-mapped list, the header data of the row (before encryption) is acquired (step S12). This is data acquired from an actual file on the hard disk 22 in advance.

  Next, the current header data (after encryption) is acquired from the address specified by the parameter “lpBaseAddress” at the time of calling (step S13). This is data acquired from the virtual file in the current memory 23.

  Next, the obtained header data before encryption and the header data after encryption are compared to determine whether or not they are different (step S14).

  If there is no difference between the header data before encryption and the header data after encryption, the ransomware detection process is immediately terminated.

  If the header data before encryption is different from the header data after encryption, the process to be monitored is detected as ransomware or its suspicion (step S15).

(Ransomware detection process (2))
Details of the ransomware detection process (part 2) will be described with reference to the flowchart of FIG.

  This is ransomware detection processing when HookCloseHandle is used.

  First, it is determined whether or not the handle specified in the parameter “hObject” at the time of calling HookCloseHandle exists in the memory-mapped list (step S21).

  If the handle does not exist in the memory mapped list, the ransomware detection process is immediately terminated.

  If the handle exists in the memory mapped list, the file path is calculated from the parameter “hObject” (step S22).

  Next, “encryption target file path” is acquired from the memory mapped list (step S23).

  Next, it is determined whether or not the file path calculated from the parameter is the same as the file path acquired from the memory mapped list (step S24).

  If the file paths are not the same, the ransomware detection process is immediately terminated.

  If the file paths are the same, the header data (before encryption) of the corresponding line is acquired (step S25). This is data acquired from an actual file on the hard disk 22 in advance.

  Next, the current header data (after encryption) is acquired from the file path (step S26). This is data acquired from an actual file on the current hard disk 22.

  Next, the obtained header data before encryption is compared with the header data after encryption to determine whether or not they are different (step S27).

  If there is no difference between the header data before encryption and the header data after encryption, the ransomware detection process is immediately terminated.

  If the header data before encryption is different from the header data after encryption, the process to be monitored is detected as ransomware or its suspicion (step S28).

(Backup process)
According to the program of the present invention, as described above, the monitoring target process can be detected as ransomware when the monitoring target process executes encryption of the first file. However, the contents of the mapped memory are already encrypted when detected as ransomware. For this reason, even if the process to be monitored is forcibly terminated, the first file cannot be encrypted.

  Therefore, when the monitored process is detected as ransomware, the file backed up by the HookCreateFileMapping function is written back as an actual file on the hard disk 22. The detection of ransomware is notified to the resident program of the present invention program, and the backed up file is written back.

  When the backup file is written back, the processing shown in (HookCreateFileMapping function) of (second function: function of recording the behavior of the process to be monitored by the hooked API) is applied.

(Third function (part 2): When the map is not explicitly closed / reflected)
Even if UnmapViewOfFile / UnmapViewOfFileEx, FlushViewOfFile, and CloseHandle are not explicitly called, the contents of the mapped memory are written to the file by the operating system (Windows OS) when the program ends. In order for the ransomware developer to escape from the monitoring of the API, it is conceivable to take a method of intentionally not performing the above-described closing process. Therefore, it is necessary to be able to detect ransomware even in such a case.

  When the above API is not explicitly called, there is no trigger for checking the difference of header data for the mapped memory. For this reason, immediately after the file is processed by the monitoring target process, it cannot be detected whether the file is encrypted.

  Therefore, in the program of the present invention, the ransomware usually focuses on the feature that files are continuously encrypted, and the detection is performed using the continuity of file encryption.

The present invention program further adds the following functions to the HookMapViewOfFile function and the HookMapViewOfFileEx function that are hook functions of MapViewOfFile and MapViewOfFileEx.
(A) A function of scanning all memory mapped lists.
(B) A function of acquiring “header data before encryption” of all lines acquired by scanning (c1) From the “encryption target file path” of all lines acquired by scanning, on the hard disk 22 The function to get the current header data from the actual file.
(C2) A function of acquiring the current header data of the virtual file on the memory 23 from the “map start address” of all the lines acquired by scanning. This case is effective only in a situation where the map start address is not reused by the OS, that is, the map start address is not duplicated in the memory mapped list. This is because when the information is reused by the OS, it may be replaced with new information.
(D) The “header data before encryption” and the “header data after encryption” in all the above lines are respectively compared, and if there is a difference, it is determined that the file encryption operation is performed by ransomware. And terminate the process.

  Even if the above functions are added to the HookMapViewOfFile function and the HookMapViewOfFileEx function, the encryption of the first file cannot be detected. This is because when the HookMapViewOfFile function and the HookMapViewOfFileEx function are executed for the first file, the encryption for the first file has not been executed yet. When the HookMapViewOfFile function and the HookMapViewOfFileEx function are executed in the encryption of the second and subsequent files, the encryption of the first file has already been executed, so that the encryption of the first file can be detected.

(Ransomware detection processing)
Ransomware detection processing by the program of the present invention will be described with reference to FIGS.

  FIG. 74 shows processing when file encryption is continuously performed by the monitoring target process.

  Step 1 (HookCreateFileMapping), Step 2 (HookMapViewOfFile / HookMapViewOfFileEx), and Step 3 (data encryption of mapped memory by ransomware) are performed on the first file.

  At the end of step 3, the memory-mapped list contains “0xABC” as the handle of the encryption target file, “C: \ test.pdf” as the file path of the encryption target, “0xABCD” as the handle of the file mapping object, “25 50 44 46 2D” is recorded in the header data before encryption, and “0x201000” is recorded in the map start address.

  After step 3 for the first file, the contents of the mapped memory are written to the file by the operating system (Windows OS) without performing explicit close processing (UnmapViewOfFile / UnmapViewOfFileEx, FlushViewOfFile, CloseHandle). Next, the second file is processed.

  Similarly, step 1 (HookCreateFileMapping), step 2 (HookMapViewOfFile / HookMapViewOfFileEx), and step 3 (mapped memory data encryption using ransomware) are performed for the second file.

  At the end of step 1, the memory mapped list contains “0xDEF” for the handle of the encryption target file, “C: \ doc.txt” for the file path of the encryption target, “0xEF01” for the handle of the file mapping object, “61 62 63 64 65” is recorded in the header data before encryption.

  Details of Step 2 (HookMapViewOfFile / HookMapViewOfFileEx) will be described using the flowchart of FIG. Ransomware detection processing using HookMapViewOfFile / HookMapViewOfFileEx.

  First, scanning of the memory mapped list is started (step S31).

  Next, it is determined whether it is the end of the memory mapped list (step S32). If it is at the end of the memory mapped list, the ransomware detection process is immediately terminated, assuming that the scanning is completed.

  If it is not the end of the memory mapped list, “header data before encryption” of the corresponding line of the memory mapped list is acquired (step S33). This is data acquired from an actual file on the hard disk 22 in advance.

  Next, the “encryption target file path” of the corresponding line in the memory mapped list is acquired (step S34). This is data acquired from an actual file on the hard disk 22 in advance.

  Next, the current header data (after encryption) is acquired from the file of “encryption target file path” in the corresponding line (step S35). This is data acquired from a real file in the current hard disk 22 or a virtual file in the current memory 23.

  Next, the acquired header data before encryption and the header data after encryption are compared to determine whether or not they are different (step S36).

  If the header data before encryption and the header data after encryption are not different, the process returns to step S32 to scan the next row of the memory mapped list.

  If the header data before encryption is different from the header data after encryption, the process to be monitored is detected as ransomware or its suspicion (step S37).

(Backup process)
According to the program of the present invention, as described above, the monitored process can be detected as ransomware when the monitored process executes the encryption of the second file. However, when detected as ransomware, the contents of the mapped memory of the first file and the second file are already encrypted. For this reason, even if the process to be monitored is forcibly terminated, the encryption of the first file and the second file cannot be prevented.

  Therefore, when the monitored process is detected as ransomware, the file backed up by the HookCreateFileMapping function is written back as an actual file on the hard disk 22. The detection of ransomware is notified to the resident program of the present invention program, and the backed up file is written back.

  When the backup file is written back, the processing shown in (HookCreateFileMapping function) of (second function: function of recording the behavior of the process to be monitored by the hooked API) is applied.

(Exclusion list)
To determine whether or not the process of the present invention program is ransomware for all processes operating on the system adds a new load to the system.

  Therefore, in this embodiment, an “exclusion list” in which programs that are clearly not ransomware are registered in advance is created, and the program of the present invention is not executed for the programs registered in the exclusion list.

  Regular programs are registered in the exclusion list. For example, “program name”, “program file”, “full file path”, “file size”, “hash value”, “digital signature”, and the like installed in the system are registered as necessary.

  The exclusion list is updated each time a program is installed in the system and stored on the hard disk 22. The contents of the exclusion list are read when the program of the present invention is started.

  After the operation of the program of the present invention, the read exclusion list information is mapped onto the memory 23. It is preferable to always update the files on the hard disk 22 so that the contents are not lost even if the memory information is volatilized due to a sudden machine trouble.

  Also, it is desirable to encrypt the exclusion list file to avoid editing by malware or ransomware.

(Process termination)
When the program of the present invention determines that the process to be monitored is ransomware, the process is forcibly terminated. The process is forcibly terminated in the hooked function. Generally, this can be realized by using the ExitProcess function, the Exit function, or the like, but any instruction that can terminate the process may be used. As a result, file encryption by ransomware can be prevented.

  It should be noted that in an environment where there is a possibility of causing a problem by terminating the process immediately, it is possible to respond to the user and ask for the termination.

[Principle of the invention (part 3)]
The principle (part 3) of the present invention will be described.

  In the ransomware encryption process confirmed by the inventors of the present application, the entire contents of the target file are encrypted, and the header information and the data part are all rewritten. In the principle of the invention (part 1) and the principle of the invention (part 2), on the assumption that the ransomware rewrites the entire contents of the target file, it is determined whether or not at least the header information of the target file has been rewritten. , Ransomware is detected.

  However, in the future, ransomware that encrypts only the data part without rewriting the file header information will appear in order to escape the ransomware detection based on the principle of the invention (part 1) and the principle of the invention (part 2). There is a possibility.

  In such ransomware encryption processing, the file format is established even after encryption, and the file can be opened with a legitimate application, but the data content cannot be confirmed, and encryption is performed by the ransomware. Will be achieved.

  In the embodiment based on the principle (part 1) of the invention and the principle (part 2) of the invention, it is difficult to detect such ransomware. The principle (part 3) of the present invention is to detect ransomware that encrypts only the data portion without rewriting the header information of the file by another method.

  First, since the contents of the data portion of the file are always rewritten by a legitimate application, ransomware cannot be detected only by whether or not the data portion has been rewritten.

  In many environments, an application that handles a specific file is associated with the operation system (OS). For example, when a file with an extension of “.doc” or “.docx” is opened, it is automatically set to be opened by a Microsoft Word application that is a prescribed application.

  Therefore, when a program that is not associated with the extension ".doc" or ".docx" changes only the data part of a file with the extension ".doc" or ".docx", the program is ransomware. It can be considered that there is a possibility.

  The principle (No. 3) of the present invention is that when a monitored program accesses a file, the monitored program is a program that is not associated with the extension of the file, and only the data portion of the file is changed. Ransomware is detected based on the determination.

  The detection that only the data part of the file has been changed includes the case where the change of the data part is detected but the change of the header information is not detected, the change of the data part is detected and the header information is changed. This includes the case where it is detected that there is nothing.

  It should be noted that in the countermeasures against the encryption of only the data part, the ransomware indicates that the application that is not associated with the extension of the file to be written may “write” to the data part rather than the “change” of the data part. It may be a priority for detection.

  Depending on the user's settings and the customized environment, the data part may be opened and edited by a program other than the prescribed application associated with the file extension. For example, the data part of a file with extensions “.doc” and “.docx” may be edited by a program other than Microsoft Word.

  In response to this, a screen for asking the user whether or not the program is the intended program is displayed and added to the white program list indicating that the program is not ransomware according to the user's answer. Thereby, it will not be repeatedly detected after that.

[Fourth Embodiment]
A program, an information processing apparatus, and an information processing method according to the fourth embodiment of the present invention will be described with reference to FIGS.

  In this embodiment, when a monitoring target program accesses a file, it is first determined whether or not the monitoring target program is a program associated with the extension of the file. When it is determined that the program is not associated, it is determined whether or not the monitoring target program has changed only the data portion of the file. If it is determined that only the data portion of the file has been changed, the monitoring target program is determined to be suspected of ransomware.

(Detection of whether the monitored program is associated with the file extension)
When the program of the present invention hooks an API from a process to be monitored, the name of the application to be accessed and the file name (extension) to be accessed are known. When reading and writing files, extract the extension of the file to be accessed, obtain the path of the associated application from the extension, compare it with the path of the application of the monitored process, and if these paths are the same, associate It is determined that the application has been deleted.

  The list of applications associated with the extension is stored as a registry value on the hard disk in the operating system (Windows OS). Therefore, the associated application can be obtained by directly reading the registry value under HKEY_CLASSES_ROOT.

  In addition to a single application associated with an extension, a list of application candidates displayed in “Select from program” displayed when the file is right-clicked can be acquired.

  FIG. 76 shows a specific example of a flow for acquiring “an application associated with an extension” from the registry area on the hard disk.

  As shown in FIG. 76, an identifier “{84F66100-FF7C-4fb4-B0C0-02CD7FB668FE}” called CLSID is acquired from the registry “HKCR \ .docx”, and this identifier “{84F66100-FF7C-4fb4-B0C0-02CD7FB668FE}” is acquired. ”To obtain the program path“ C: \ Program Files \ Microsoft Office \ Office15 \ WINWORD.EXE ”associated with the extension“ .docx ”.

  As a simpler method, you can call "C: \ Program Files \ Microsoft Office \ Office15 \ WINWORD.EXE" by calling the operating system (Windows OS) AssocQueryString API with an extension such as ".docx". You can get the location of the application as follows.

  For example, in the HookCreateFileMapping function, FIG. 77 shows a flow for determining whether or not an application that is to encrypt a file is an application associated with the extension of the file.

  To get the associated application:

  First, the file handle “0x6C” is acquired from the HookCreateFileMapping function.

  Next, the file path “C: \ users \ test \ Desktop \ test.doc” of the access target file is acquired from the file handle using GetFinalPathNameByHandle or the like.

  Next, only the extension “.doc” is cut out from the acquired file path “C: \ users \ test \ Desktop \ test.doc”.

  Next, the application “C: \ Program Files \ Microsoft Office \ Office15 \ WINWORD.EXE” associated with the extracted extension “.doc” is obtained using AssocQueryString.

On the other hand, for the process to be monitored, GetModuleFileName or the like is used to acquire its own path “C: \ Program Files \ Microsoft Office \ Office15 \ WINWORD.EXE”.

  Then, the application associated with the extension acquired in this way is compared with the path of the monitored process itself. If they match, it is determined that the data is changed by the application associated with the extension, so that it is not encrypted. If they do not match, it is determined that there is a possibility of encryption because the data is changed by an application not associated with the extension.

(Header and data part of the file)
In the program of the present invention, it is necessary to determine whether the place to be written is the header part or the data part. Therefore, a method for determining the header portion and the data portion of the file will be described.

  The position and size of the header part are defined and published for each application. Basically, it follows the format of each published file. In the program of the present invention, the invariant portion of the header information in each file format that has been made public is used as the header information of the file format.

  For example, FIG. 78 (a) is a part of a published format of a bitmap file which is an image format. Information such as a file header, an information header, and a color table is recorded in the header portion. Pixel data (image data) is recorded in the data portion.

  However, all data in the header part is not a fixed value. For example, the data “F6 93 25 00” value of the third byte (address “00000002”) in the header part of FIG. 78A indicates the file size of the bitmap file. If the file size of the image file changes, the data in this part also changes.

  In the present invention, a portion that does not change unless the file type changes is referred to as a “header portion of the present invention”. For example, in the bitmap file, as shown in FIG. 78 (b), the first two bytes “42 4D” (character string “BM”) of the header portion are set to “header portion of the present invention”, and the other portions are set to [Books]. The data portion of the invention ".

  The portions that do not change do not necessarily have to be continuous unless the file type changes. The discontinuous unchanging part may be referred to as the “header part of the present invention”. For example, in FIG. 78 (b), “42 4D xx xx xx xx 00 00 00 00” excluding 3 to 6 bytes may be used as the “header portion of the present invention”. “Xx” indicates a variable byte.

  If the file format is not disclosed or the size of the header part is not disclosed, the head part of the file may be the header part and the other part may be the data part. In this case, the size of the head part is arbitrary, but generally several bytes to several tens of bytes are set. If there are many false detections as a result of trying to detect ransomware, the size can be adjusted.

(General file operations and file operations by file mapping)
As described above, general file operations and file operations based on file mapping are possible as file operations.

  Real files are stored on the hard disk. In each file read / write process in a general file operation, a series of processes such as preparing a buffer (not shown) in the memory, reading the file, and writing the edited data back to the file are performed.

  In the file operation by file mapping, the entire real file stored in the hard disk 22 is expanded as a virtual file (file mapping object) in the memory. In the file operation by file mapping, each time the contents of the file are rewritten, the contents are rewritten with respect to the virtual file expanded in the memory. The change result of the file contents is reflected in the actual file on the hard disk at the final stage of the series of processing.

  The principle (part 3) of the invention can be applied to general file operations and file operations by file mapping.

(File operation by file mapping)
A case where the principle (part 3) of the invention is applied to file operation by file mapping will be described.

  The program of the present invention has the same three functions as in the second embodiment.

  The first function is a function for hooking a Windows API used by a monitoring target process that is a program that is currently operating or a program that is activated later.

  The second function is a function for recording the behavior of the process to be monitored by the hooked Windows API.

  The third function is a function for determining whether or not the ransomware is based on the behavior recorded by the second function.

(Hook function and additional functions)
The Hook function and functions added to it in this embodiment will be described.

  The hook target API in the present embodiment is as follows, as in the third embodiment.

CreateFileMapping
MapViewOfFile / MapViewOfFileEx
UnmapViewOfFile / UnmapViewOfFileEx
FlushViewOfFile
CloseHandle
In the present embodiment, the following function is added to the hook function for hooking the hook target API.
(A) A function for confirming whether its own process is a predetermined program.
(B) When registering “header data before encryption of encryption target file” of the HookCreateFileMapping function in the memory-mapped list, also obtain “hash value of data part before encryption of encryption target file” The function to register.
(C) A function of acquiring “the hash value of the data part after encryption (when the hook function is called)” in the HookMapViewOfFile function, HookMapViewOfFileEx function, HookUnmapViewOfFile function, HookUnmapViewOfFileEx function, FlushViewOfFile function, and CloseHandle function.
(D) A function to detect when the process is not a default program and when the obtained hash values of the data part before and after encryption are different from each other.

(Summary of the third function)
The operation when the map close / reflect processing is explicitly performed will be described in time series with reference to FIG.

  First, in step 1, a new line is added to the memory-mapped list by HookCreateFileMapping. In the new row, the handle of the encryption target file, the encryption target file path, the handle of the file mapping object, the header data before encryption of the encryption target file, and the hash value of the data part before encryption are entered.

  In FIG. 79, the handle of the encryption target file is “0xABC”, the encryption target file path is “C: \ test.pdf”, the handle of the file mapping object is “0xABCD”, and the encryption target file is The header data before encryption is “25 50 44 46 2D”, and the hash value of the data part before encryption is “4669... CBD7”.

  Next, in step 2, the start address of the map is entered in the memory mapped list by HookMapViewOfFile / HookMapViewOfFileEx.

  In FIG. 79, since the file mapping object handle “0xABCD” specified as the parameter at the time of calling exists in the memory mapped list, the map start address “0x201000” is added to the line.

  Next, in step 3, if the monitored process is ransomware, the data in the mapped memory is encrypted.

  Next, in step 4, by using HookUnmapViewOfFile / HookUnmapViewOfFileEx or HookFlushViewOfFile, first, a search is made from the “map start address” column that matches the address specified in the parameter when calling UnmapViewOfFile / UnmapViewOfFileEx or HookFlushViewOfFile. (Step 4-3).

  Next, if there is a matching row, the hash value of the data portion (before encryption) of the row and the hash value of the current data portion (after encryption) obtained from the mapped memory are calculated. Subsequently, the hash value of the data part before encryption and the hash value of the data part after encryption are compared, and if there is a difference, it is determined that the data part is encrypted. In this way, it is determined whether or not the process to be monitored is ransomware (step 4-2).

  In FIG. 79, the hash value “4669 .... CBD7” of the data part before encryption is acquired from the parameter “0xABCD” at the time of calling, and the address “0x201000” specified by the parameter “0xABCD” at the time of calling is acquired. To obtain the hash value “B66A1 ..... 40AB” of the current encrypted data part. Since there is a difference when these are compared, it is determined that the process to be monitored is ransomware.

  If the hash value of the data part cannot be acquired correctly for some reason, the second file is the same as (third function (part 2): when the map is not explicitly closed / reflected). Attempt detection at the initial stage of encryption processing (MapViewOfFile / Ex call timing).

(Ransomware detection processing)
Details of the ransomware detection process will be described with reference to the flowchart of FIG.

  This is ransomware detection processing when HookUnmapViewOfFile / HookUnmapViewOfFileEx or HookFlushViewOfFile is used.

  First, it is determined whether or not the address specified in the parameter “lpBaseAddress” at the time of calling UnmapViewOfFile / UnmapViewOfFileEx or HookFlushViewOfFile exists in the memory mapped list (step S41).

  If the address does not exist in the memory mapped list, the ransomware detection process is immediately terminated.

  If the address exists in the memory mapped list, the header data (before encryption) of the row is acquired (step S42). This is data acquired from an actual file on the hard disk 22 in advance.

  Next, the current header data (after encryption) is acquired from the address specified by the parameter “lpBaseAddress” at the time of calling (step S43). This is data acquired from the virtual file in the current memory 23.

  Next, the obtained header data before encryption is compared with the header data after encryption to determine whether or not they are different (step S44).

  If the header data before encryption is different from the header data after encryption, the process to be monitored is detected as ransomware or its suspicion (step S45).

  If there is no difference between the header data before encryption and the header data after encryption, it is determined whether the monitoring target program itself is an application associated with the extension of the target file (step S46).

  If the monitored program is an application associated with the extension of the target file, the ransomware detection process is immediately terminated.

  If the monitoring target program is not an application associated with the extension of the target file, the hash value of the data part before encryption of the corresponding line is acquired (step S47). This is data acquired from an actual file on the hard disk 22 in advance.

  Next, the current data part is acquired from lpBaseAddress (mapped memory), and the hash value is calculated (step S48). This is data acquired from the virtual file in the current memory 23.

  Next, the hash value of the data part before encryption is compared with the hash value of the current data part to determine whether or not they are different (step S49).

  If the hash value of the data part before encryption is different from the hash value of the data part after encryption, the process to be monitored is detected as ransomware or its suspicion (step S45).

  If the hash value of the data part before encryption is not different from the hash value of the data part after encryption, the ransomware detection process is terminated.

(General file operations)
The case where the principle (part 3) of the invention is applied to general file operations will be described.

  In each file read / write process in general file operations, a series of processes such as preparing a buffer (not shown) in memory, reading the actual file on the hard disk, and writing the edited data back to the file are performed. Do.

  In the case of a general file operation, the monitoring target program is an application that is not associated with the extension of the target file, and detects whether WriteFile is called for the data portion.

In the present embodiment, the following processing is added to the HookWriteFile function that hooks WriteFile.
(A) A function for confirming whether its own process is a predetermined program.
(B) A function to detect when its own process is not a default program.

  Details of the ransomware detection processing will be described with reference to the flowchart of FIG.

  This is ransomware detection processing when the HookWriteFile function is used.

  First, it is determined whether or not the write target file exists in the past ReadFile record (step S51). The past ReadFile record is the ReadFile notification record data as shown in FIG. Here, the process ID of ReadFile and the file path are sequentially recorded.

  If the file to be written does not exist in the past ReadFile record, the ransomware detection process is immediately terminated.

  If the write target file exists in the past ReadFile record, it is determined whether or not the write target position is within the header range (step S52).

  When the write target position is within the header range, the header data (before encryption) of the row is acquired (step S53). This is data acquired from an actual file on the hard disk 22 in advance.

  Next, the current header data (after encryption) is acquired from the contents of the write data (step S54). This is data acquired from the virtual file in the current memory 23.

  Next, the acquired header data before encryption and the header data after encryption are compared to determine whether or not they are different (step S55).

  If the header data before encryption is different from the header data after encryption, the process to be monitored is detected as ransomware or its suspicion (step S56).

  If there is no difference between the header data before encryption and the header data after encryption, the ransomware detection process is immediately terminated.

  If it is determined in step S52 that the write target position is not within the header range, it is determined whether the monitoring target program itself is an application associated with the extension of the target file (step S57).

  If the monitored program is an application associated with the extension of the target file, the ransomware detection process is immediately terminated.

  If the monitoring target program is not an application associated with the extension of the target file, the data portion before writing (data of the writing target portion) is acquired (step S58). This is data acquired from the actual file on the current hard disk 22.

  Next, write target data is acquired (step S59). This is data acquired from the buffer of the current memory 23.

  Next, it is determined whether or not the contents of data before and after writing are different (step S60). That is, the data of the write target part before writing acquired in step S58 and the write target data acquired in step S59 are compared to determine whether or not they are different (step S60).

  If the contents of the data before and after writing are different, the process to be monitored is detected as ransomware or its suspicion (step S56).

  If there is no difference between the data contents before and after writing, the ransomware detection process is terminated.

  In the above embodiment, the change of the header data by the write command to the file (WriteFile) or the change of the data before and after the writing of the data part is detected, but other file structures other than the change of the header data and the data part of the data part are detected. A change to an inappropriate state may be detected.

(Modified embodiment of general file operation)
A modified embodiment in which the principle (part 3) of the invention is applied to general file operations will be described.

  In the above description of the fourth embodiment, when it is detected that the monitoring target program is not an application associated with the extension of the target file and it is detected that the data before and after writing by WriteFile is different, the monitoring target process Is detected as ransomware or its suspicion.

  However, it can be said that the call to WriteFile clearly shows the intention to write by the monitored program. Even if the difference between data before and after writing by WriteFile is not detected, the process to be monitored may be detected as ransomware or its suspicion.

  Details of such ransomware detection processing will be described with reference to the flowchart of FIG.

  This is ransomware detection processing when the HookWriteFile function is used.

  First, it is determined whether or not the write target file exists in the past ReadFile record (step S71). The past ReadFile record is the ReadFile notification record data as shown in FIG. Here, the process ID of ReadFile and the file path are sequentially recorded.

  If the file to be written does not exist in the past ReadFile record, the ransomware detection process is immediately terminated.

  If the write target file exists in the past ReadFile record, it is determined whether or not the write target position is within the header range (step S72).

  If the write target position is within the header range, the header data (before encryption) of that line is acquired (step S73). This is data acquired from an actual file on the hard disk 22 in advance.

  Next, the current header data (after encryption) is acquired from the contents of the write data (step S74). This is data acquired from the virtual file in the current memory 23.

  Next, the acquired header data before encryption is compared with the header data after encryption to determine whether or not they are different (step S75).

  If the header data before encryption is different from the header data after encryption, the process to be monitored is detected as ransomware or its suspicion (step S76).

  If there is no difference between the header data before encryption and the header data after encryption, the ransomware detection process is immediately terminated.

  If it is determined in step S72 that the write target position is not within the header range, it is determined whether the monitoring target program itself is an application associated with the extension of the target file (step S77).

  If the monitoring target program is not an application associated with the extension of the target file, the monitoring target process is detected as ransomware or its suspicion (step S76).

  If the monitoring target program is an application associated with the extension of the target file, the ransomware detection process is terminated.

  In the modified embodiment, the change of the header data due to the write command to the file (WriteFile) is detected, but the change of the head data may not be detected. Further, a change to an inappropriate state of the file structure other than the change of the header data or the data of the data portion may be detected.

[Modified Embodiment]
The present invention is not limited to the above embodiment, and various modifications can be made.

  For example, in the above embodiment, the present invention is applied to Microsoft Windows, which is a Microsoft operating system, but Android, BSD, iOS, Linux, OS X, Windows Phone, IBM z / OS (all registered trademarks). The present invention may be applied to other operating systems. Ransomware attacks against each operating system can be reliably and effectively prevented.

  In the above embodiment, the present invention is applied when an actual file is recorded on a hard disk. However, a storage other than a hard disk, for example, a storage using a semiconductor element memory such as a solid state drive (SSD), a portable The present invention may be applied when a real file is recorded in a storage using a semiconductor element memory used for a telephone, a smartphone, or the like.

10 ... Information processing device 20 ... Computer (PC)
30 ... External peripheral device 21 ... CPU
22 ... Hard disk 23 ... Memory 24 ... Input / output device 25 ... Display 31 ... Printer 32 ... External storage device

The next capture in Fig. 8 (c) shows that "C: \ Users \ Publi c \ *", which is a folder lower than the folder "C: \ Users \ *", is passed to FindFirstFileW as an argument. Show.

In the next capture shown in Fig. 8 (d), "C: \ Users \ Public \ Videos \ *", which is a folder below the folder "C: \ Users \ Public \ *", is passed to FindFirstFileW as an argument. It has been shown.

FIG. 10 shows the state of the file “Wildlife.wmv” before and after being accessed by the ransomware CryptoWall. 10A shows a state before being accessed by the ransomware CryptoWall, and FIG. 10B shows a state after being accessed by the ransomware CryptoWall.

The interval for periodically clearing the notification record data is arbitrary, but it is desirable to clear it at the time of termination or restart of the operating system at the longest. The clear interval may be set by the user.

The hook write file incorporated in the monitoring target process on the left side of FIG. 22 (a) is based on the process ID of itself (monitoring target process) and the target file path of WriteFile. The process is inquired of whether there is a record of ReadFile with the same process ID and the same target file path in ReadFile notification record data. FIG. 22 (a) The present invention program on the right side responds to HookWriteFile whether there is a record of ReadFile with the same process ID and the same target file path.

The incorporated HookReadFile notifies (a) the notification source API name, (b) its own process ID, and (c) the ReadFile target file path to the process of the present invention on the right side of FIG. 26 in addition to the normal ReadFile operation . .

The notification record data in FIG. 37 includes records of FindNextFile process ID “pid: 1568” and file path “C: \ Users \ user \ Documents \ schedule.xls” in the fourth to sixth lines. Lines 9 and 13 to 15 have a record of ReadFile process ID “pid: 1568” and file path “C: \ Users \ user \ Documents \ schedule.xls”. Lines 10 to 12 and 16 to 16 On line 18 , there is a record of WriteFile process ID “pid: 1568” and file path “C: \ Users \ user \ Documents \ schedule.xls”.

FIG. 38 is a setting screen for enabling detection of encryption processing for a plurality of files. The expression method of the setting screen in FIG. 38 is an example, and other expression methods may be used . On the setting screen, after the check button, “Enter encryption processing for multiple files with detection conditions” is displayed, and “If you do not check, encryption processing for single files is also included in the detection target.” Displays a note of. The detection condition can be changed when the user checks the check button.

To determine the above, for example, HookReadFile, HookWriteFile, respectively, notifies the present invention program (a) the reporting API name, (b) process ID, (c) file path, MoveFile is, the present invention (A) Notification source API name to be notified to the program, (b) Process ID, (c) File path of the first argument, (d) File path of the second argument are recorded in the notification record data, Judgment is made based on the notification record data.

The warning screen asks "The following process is changing the text file. How do you handle it?", "Process: AAAA.exe", "Applicable behavior: File content modification, file name modification, we are trying to change to "d1g2r.vvv""," Target file: shows the \ Users \ test \ Document \ BBB.pdf ": C.

The first embodiment of the present invention analyzes the behavior of main ransomware, identifies common parts, and detects and protects behaviors that can be determined to be illegal from there. However, even without a technique analysis by the ransomware, defense of encryption processing of the file is possible.

Condition 3: The file of the first argument of MoveFile is included in the list B. That is, the process ID notified from HookWriteFile is the same as the process ID notified from HookMoveFile , and the file path notified from HookWriteFile is the same as the file path of the first argument notified from HookMoveFile.

In Figure 59, “ Encryption target file handle ” is “0xABC”, “ Encryption target file path ” is “C: \ test.pdf”, and “ File mapping object handle ” is “0xABCD”. There, it is shown that "unencrypted header data of the encrypted target file" is "25 50 44 46 2D".

(Third function: a function for determining whether or not the ransomware is using a record)
The third function of the program of the present invention determines whether or not the process to be monitored is ransomware based on the behavior recorded by the second function. There are cases where the monitoring target process explicitly performs the map closing / reflecting process, and there are cases where the map closing / reflecting process is not explicitly performed, and the process is performed assuming each case.

First, to start the scanning of the memory-mapped list (step S31).

Claims (23)

Computer
A first condition that a real file on the disk is mapped on the memory as a virtual file corresponding to the real file by a predetermined process, and a second condition that the virtual file is unmapped by the predetermined process And the third condition that the file structure of the real file or the virtual file at the time of unmapping is changed to an inappropriate state, and a determination unit that determines the predetermined process as ransomware Program to function as. Computer
A first condition that a real file on the disk is mapped on a memory as a virtual file corresponding to the real file by a predetermined process; a fourth condition that the first condition occurs continuously; Function as a determination unit that determines that the predetermined process is ransomware when the third condition that the file structure of the real file or the virtual file at the time of unmapping is changed to an inappropriate state is satisfied Program to let you. The program according to claim 1 or 2,
The program according to claim 3, wherein the third condition is that header information of the real file at the time of mapping is different from header information of the real file or the virtual file at the time of unmapping. Computer
A first condition that a real file on a disk is mapped on a memory as a virtual file corresponding to the real file by a predetermined process, and a program in which the predetermined process is not associated with the file type of the real file. The predetermined process is satisfied when the fifth condition of being present and the sixth condition that the information of the real file at the time of mapping is different from the information of the real file or the virtual file at the time of unmapping are satisfied. Program that functions as a deciding part to determine ransomware. The program according to any one of claims 1 to 4,
The determination unit determines that the first condition is satisfied when an instruction to create the virtual file or an instruction to map the virtual file to the memory is called by the predetermined process. Program to do. The program according to claim 1,
When the predetermined process calls an instruction to unmap the virtual file from the memory, an instruction to write a part of the virtual file to the disk, or an instruction to close the handle of the virtual file by the predetermined process And determining that the second condition is satisfied. The program according to claim 2,
The determination unit determines that the fourth condition is satisfied when an instruction to create the virtual file or an instruction to map the virtual file to the memory is continuously called by the predetermined process. A program characterized by The program according to any one of claims 1 to 7,
The computer further,
When the real file is mapped on the memory as the virtual file by the predetermined process, a backup file is generated that backs up the real file, and the determination unit determines that the predetermined process is ransomware A program for causing the backup file to function as a backup unit for writing back the backup file to the actual file on the disk. Computer
A seventh condition that a write command to a real file on the disk is issued by a predetermined process, and an eighth condition that the predetermined process is a program not associated with the file type of the real file. When satisfied, a program for causing the predetermined process to function as a determination unit that determines to be ransomware. The program according to claim 9, wherein
The determination unit determines that the predetermined process is ransomware when the ninth condition that the file structure of the real file is changed to an inappropriate state by the write command is further satisfied. Program. On the computer,
A first condition that a real file on the disk is mapped on the memory as a virtual file corresponding to the real file by a predetermined process, and a second condition that the virtual file is unmapped by the predetermined process And the third condition that the file structure of the real file or the virtual file at the time of unmapping is changed to an inappropriate state, and a determination unit that determines the predetermined process as ransomware A program that executes On the computer,
A first condition that a real file on the disk is mapped on a memory as a virtual file corresponding to the real file by a predetermined process; a fourth condition that the first condition occurs continuously; When the third condition that the file structure of the actual file or the virtual file at the time of unmapping is changed to an inappropriate state is satisfied, a determination unit that determines the predetermined process as ransomware is executed Program to make. On the computer,
A first condition that a real file on a disk is mapped on a memory as a virtual file corresponding to the real file by a predetermined process, and a program in which the predetermined process is not associated with the file type of the real file. The predetermined process is satisfied when the fifth condition of being present and the sixth condition that the information of the real file at the time of mapping is different from the information of the real file or the virtual file at the time of unmapping are satisfied. A program that executes a judgment means that judges that ransomware. On the computer,
A seventh condition that a write command to a real file on the disk is issued by a predetermined process, and an eighth condition that the predetermined process is a program not associated with the file type of the real file. A program that, when satisfied, executes determination means for determining the predetermined process as ransomware.   The computer-readable recording medium which recorded the program of any one of Claims 1 thru | or 14. A first condition that a real file on the disk is mapped on the memory as a virtual file corresponding to the real file by a predetermined process, and a second condition that the virtual file is unmapped by the predetermined process And the third condition that the file structure of the real file or the virtual file at the time of unmapping is changed to an inappropriate state, and a determination unit that determines the predetermined process as ransomware An information processing apparatus comprising: A first condition that a real file on the disk is mapped on a memory as a virtual file corresponding to the real file by a predetermined process; a fourth condition that the first condition occurs continuously; A determination unit that determines that the predetermined process is ransomware when the third condition that the file structure of the real file or the virtual file at the time of unmapping is changed to an inappropriate state is satisfied; An information processing apparatus characterized by that. A first condition that a real file on a disk is mapped on a memory as a virtual file corresponding to the real file by a predetermined process, and a program in which the predetermined process is not associated with the file type of the real file. The predetermined process is satisfied when the fifth condition of being present and the sixth condition that the information of the real file at the time of mapping is different from the information of the real file or the virtual file at the time of unmapping are satisfied. An information processing apparatus, comprising: a determination unit that determines ransomware. A seventh condition that a write command to a real file on the disk is issued by a predetermined process, and an eighth condition that the predetermined process is a program not associated with the file type of the real file. An information processing apparatus comprising: a determination unit that determines that the predetermined process is ransomware when satisfied. A first condition that a real file on the disk is mapped on the memory as a virtual file corresponding to the real file by a predetermined process, and a second condition that the virtual file is unmapped by the predetermined process And the third condition that the file structure of the real file or the virtual file at the time of unmapping is changed to an inappropriate state, the predetermined process is determined to be ransomware. A characteristic information processing method. A first condition that a real file on the disk is mapped on a memory as a virtual file corresponding to the real file by a predetermined process; a fourth condition that the first condition occurs continuously; When the third condition that the file structure of the real file or the virtual file at the time of unmapping is changed to an inappropriate state is satisfied, the predetermined process is determined as ransomware. Information processing method. A first condition that a real file on a disk is mapped on a memory as a virtual file corresponding to the real file by a predetermined process, and a program in which the predetermined process is not associated with the file type of the real file. The predetermined process is satisfied when the fifth condition of being present and the sixth condition that the information of the real file at the time of mapping is different from the information of the real file or the virtual file at the time of unmapping are satisfied. An information processing method characterized by judging ransomware. A seventh condition that a write command to a real file on the disk is issued by a predetermined process, and an eighth condition that the predetermined process is a program not associated with the file type of the real file. If satisfied, the predetermined process is determined as ransomware.