RU2794713C1 - Method of detection of a malicious file using the database of vulnerable drivers - Google Patents

Abstract

FIELD: information security.

SUBSTANCE: invention is intended to detect malicious files that use drivers. Results are achieved by applying a malicious file detection method implemented on a computing device that includes a processor and memory, which detects driver activity in the operating system by intercepting the driver's API request to the application; determining, based on the driver activity analysis, whether the driver is dangerous; in the event that the driver is found dangerous by the results of the analysis, a search is made for the file associated with the application using the driver; the found file is recognized as malicious.

EFFECT: detecting malicious files by analysing the operation of the driver accessed by the application with which the specified file is associated. Additional effect is improvement of the accuracy of malicious file detection by detecting and analysing a dangerous driver used by the specified file.

9 cl, 3 dwg

Description

Technical field

The invention relates to the field of information security and is intended to detect malicious files that use drivers.

State of the art

The rapid development of computer technology in the last decade, as well as the widespread use of various computing devices (personal computers, laptops, tablets, smartphones, etc.) have become a powerful incentive to use these devices in various fields of activity and to perform a huge number of tasks (from the Internet -surfing to bank transfers and electronic document management). In parallel with the growth in the number of computing devices and the amount of software (SW) running on these devices, the number of malicious programs has also grown rapidly.

At the moment, there are a huge number of varieties of malicious programs. Some steal from users' devices their personal and confidential data (for example, logins and passwords, bank details, electronic documents). Others form so-called botnets from user devices for such attacks on other computers or computer networks as a denial of service (DDoS - Distributed Denial of Service) or for brute force passwords. ). Still others offer users paid content through intrusive advertising, paid subscriptions, sending SMS to paid numbers, etc.

Modern software has become so complex and multifunctional that it has become possible to use its essentially legal parts (in the form of libraries, program modules, or functions provided by API) by malicious programs for their work. For example, ransomware can use libraries of legitimate archivers to encrypt documents and other files that are critical to users.

This approach to the operation of malware significantly complicates the work of anti-virus software due to the fact that some of the malicious activity is carried out through legitimate programs that cannot be blocked or removed, since this may cause a failure in the user's computer or lead to the loss of data important to the user. In addition, often the mentioned parts of legal programs work in kernel mode (for example, drivers), which also complicates the overall control of malicious activity by antivirus software.

To partially solve the problem described above, combined malware detection methods are used, when malicious activity is detected both in kernel mode and in user mode, and the results of such monitoring are combined and analyzed.

Patent publication US8397297B2 describes a technique for removing a detected malicious application. The elements of the operating system associated with the detected malicious application are preliminarily determined (in particular, the files used by the specified malicious application). This connection is established by monitoring the execution of a potentially malicious application. In one case, applications that may be loaders of the malicious application being removed are also removed, since all elements related to the malicious application being removed are removed from the system.

Patent publication US20150096028A1 describes a technology for detecting malware (including drivers) running in the kernel mode of the operating system. To do this, a dynamic check of the execution of the operating system kernel code is performed in order to detect unauthorized interception of calls and code changes in the kernel, as well as in loadable kernel modules (drivers).

The described technologies do a good job of detecting malware running both in the kernel mode of the operating system and in user mode, and also allow you to detect malware generated on the victim's computer by other malware, but they do not cope well with situations where the malware runs immediately. both in operating system kernel mode and in user mode, when using legal components that also work in operating system kernel mode.

The present invention is designed to detect malicious files using legitimate drivers (including those signed and related to legitimate software).

Disclosure of invention

The invention is intended to ensure information security.

The technical result consists in detecting a malicious file by analyzing the operation of the driver accessed by the application with which the specified file is associated.

Another technical result is to increase the accuracy of detecting a malicious file by detecting and analyzing a dangerous driver used by the specified file.

This result is achieved by using a computer-implemented method for detecting a malicious file, implemented on a computing device, including a processor and memory, with the help of which: detect driver activity in the operating system by intercepting the driver's API request to the application; determining, based on the driver activity analysis, whether the driver is dangerous; if the driver is considered dangerous according to the results of the analysis, they search for the file associated with the application using the driver; recognize the found file as malicious.

In another particular case, the implementation of the method in the first step detects the activity of a driver running in user mode with the help of another driver running in kernel mode.

In another particular case of the implementation of the method, the activity of the driver consists at least in: data transmission over a computer network; interaction with operating system services, including by calling API functions provided by the operating system; interaction with an application running in the operating system, including by calling the corresponding API functions provided by the specified application; interaction with a file or file structure, including interaction with a file associated with an application running in the operating system, including by calling the appropriate API functions provided by the specified application.

In another particular case of the implementation of the method, as a result of analyzing the activity of the driver, the danger factor of the driver is determined and, if the danger factor exceeds the threshold value, the file associated with the application using the driver is searched.

In another particular case of the implementation of the method, the driver hazard coefficient is a numerical value from the range, one boundary of which means a guaranteed non-dangerous driver, and the other boundary is a driver guaranteed to be used to damage the computing device.

In another particular case of the implementation of the method, the analysis of driver activity consists in at least one of: identifying the analyzed driver with a known driver from the database of dangerous drivers; simulation of the analyzed driver in a virtual environment; in this case, the result of the analysis is the recognition of the analyzed driver as safe or dangerous.

In another particular case of the implementation of the method, the driver is considered dangerous if the analysis reveals at least: a security vulnerability in the driver; potentially dangerous driver functionality.

In another particular case of the implementation of the method, a potentially dangerous functionality is a functionality that can be used hidden from the user and, at the same time, damage the performance of the computing device.

In one more particular case of the implementation of the method, the found file is recognized as malicious as a result of an anti-virus scan and a decision on the harmfulness of the file, taking into account the definition of the driver as dangerous.

In another particular case of the implementation of the method, after performing a search for a file associated with an application using the driver, the found file is additionally checked for maliciousness.

In another particular case of implementing the method, if the found file is recognized as malicious, the found file is additionally quarantined and at least: it is deleted from the operating system; removal of a dangerous driver from the operating system.

Brief description of the drawings

Fig. 1 is a block diagram of a malicious file detection system.

Fig. 2 is a block diagram of a malicious file detection method.

Fig. 3 represents an example of a general purpose computer system, a personal computer or a server.

Although the invention may have various modifications and alternative forms, the characteristic features shown by way of example in the drawings will be described in detail. It should be understood, however, that the purpose of the description is not to limit the invention to a particular embodiment thereof. On the contrary, the purpose of the description is to cover all changes, modifications included in the scope of this invention, as defined by the attached claims.

Description of embodiments of the invention

The objects and features of the present invention, methods for achieving these objects and features will become apparent by reference to exemplary embodiments. However, the present invention is not limited to the exemplary embodiments disclosed below, but may be embodied in various forms. The gist of the description is nothing but the specific details necessary to assist a person skilled in the art in a thorough understanding of the invention, and the present invention is defined within the scope of the appended claims.

Fig. 1 is a block diagram of a malicious file detection system.

The block diagram of the malicious file detection system consists of an interceptor 110 , an activity analysis tool 120 , a database of dangerous drivers 121 , a search tool 130 , a malware checker 140 , a quarantine tool 150 .

The means described below are implemented as elements of a computer system or collection of computer systems, described in more detail in FIG. 3 .

The interceptor 110 is designed to detect the activity of the driver 101 in the operating system by intercepting the API request of the driver 101 to the application 102 .

In one embodiment, the interceptor 110 detects the activity of a user-mode driver 101 using another kernel-mode driver.

For example, the described system may be part of anti-virus software, one of the components of which is a kernel-mode driver that intercepts API calls between different operating system objects (operating system services, applications, libraries, other drivers, etc.).

In another implementation of the system, the interception tool 110 monitors the activity of drivers 101 that meet the criteria:

• the driver is legitimate (ie it is signed and has a verified digital signature, or installed into the operating system as a result of installing legitimate software);

• the driver is not safe or is not known for the described system (in particular for the anti-virus software used to check drivers), ie. the driver was previously determined to be dangerous or potentially dangerous, or such a check was not performed and the driver remains with an undetermined status.

For example, there are legitimate drivers that are part of software developed by legitimate manufacturers and are designed to perform actions that are safe for the user. However, they may contain vulnerabilities, or they may implement functionality that attackers can use in malware to perform dangerous actions, including from the operating system kernel. Interceptor 110 monitors just such drivers.

In another embodiment, the interceptor 110 monitors the activity of drivers 101 for which at least:

• it is already known that they were used by malicious programs earlier for malicious activity (and not necessarily at the user of the described system);

• it is determined that the indicated drivers can be used by malware (they have vulnerabilities, provide functionality that can be used in malicious activities, etc.).

For example, not all drivers in the operating system are tracked, but only drivers 101 that communicate with applications over the network, bypassing the network gateway (for example, because they are on the exclusion list).

In another implementation of the system, the activity of the driver 101 is at least:

• data transmission over a computer network;

• interaction with operating system services, including by calling API functions provided by the operating system;

• interaction with the application 102 running in the operating system, including by calling the corresponding API functions provided by the specified application 102 ;

• interaction with files or file structure, including interaction with the file 103 associated with the application 102 operating in the operating system, including by calling the appropriate API functions provided by the specified application 102 .

In one embodiment of the system, the described system can be applied to situations where the driver 101 is associated with multiple applications 102 , whereby each application 102 may in turn be associated with multiple files 103 .

For example, when working with the file archiving driver 101 , two applications 102 can be identified - a certified archiver, widely used by users, and a little popular application. Both identified by a certified archiver and a little-used application, several files can be associated at once, while all files of a certified archiver are trusted (i.e. verified, for which the absence of malicious functionality has been proven), and some of the files of a little-used application can have malicious functionality detected during anti-virus analysis.

Thus, the use of the described system to detect a malicious file 103 associated with an application 102 can also, without any fundamental changes, be reduced to the detection of malicious files 103 associated with several applications 102 (it is not necessary, but it is possible that one file 103 be associated with several applications 102 ).

The activity analyzer 120 is designed to determine, based on the activity analysis of the driver 101, whether the driver 101 is dangerous, i. whether driver 101 can be used by malware for malicious activity.

In one of the system implementation options, the activity analyzer 120 is additionally designed to determine the driver hazard ratio as a result of the driver activity analysis 101 , while the driver hazard ratio is a numerical value from the range, one border of which means a guaranteed non-dangerous driver, and the other border - the driver, guaranteed to be used to damage a computing device.

For example, the Hazard Ratio can range from 0 to 1, and its calculation is based on the weights assigned to each type of activity.

In yet another example, a trained model may be used to calculate a hazard quotient.

In another embodiment of the system, the analysis of the activity of the driver 101 is at least one of:

• identification of the analyzed driver 101 with a known driver from the database of dangerous drivers 121 ;

• simulation of the analyzed driver 101 in a virtual environment;

while the result of the analysis is the recognition of the analyzed driver 101 safe or dangerous.

In another embodiment of the system, the analysis of the activity of the driver 101 consists in simulating its operation. To this end, by any method known from the prior art, a virtual environment is implemented in the described system, simulating the operation of a computing system in which the driver 101 is installed. In a virtual environment, without any damage to the real computing system, different scenarios for using the driver 101 are executed, the results of which determine whether the driver 101 is dangerous.

Dangerous Driver Database 121 contains at least:

• drivers recognized as dangerous;

• metadata describing drivers that are considered dangerous;

• sections of driver code containing vulnerabilities;

• metadata describing the code of drivers containing vulnerabilities.

In another implementation of the system, the driver is considered dangerous, at least if:

• Previously, the activity analysis tool 120 found the driver to be dangerous, ie. the driver can be used by malware for malicious activity (for example, the driver contains vulnerabilities that allow it to be used by third-party programs, the driver’s functionality initially has a “dual” purpose, so it can be used for malicious activity (in a particular case, these may be drivers responsible for encryption data));

• the driver has already been used by malicious programs for malicious activity (both on the computer on which the described system is running and on any other computer, in which case the database of dangerous drivers 121 is formed in advance based on the collected statistics on the operation of known drivers);

• the driver has previously been analyzed by any method known from the prior art and found suitable for use by malware for malicious activity.

In another implementation of the system, the metadata describing the drivers recognized as dangerous are at least:

• parameters that allow identifying the driver (unambiguously or with some specified error), for example, the size of the driver file, file name, creation time, convolutions by the driver code, API functions used, etc.;

• parameters describing the behavior of the driver, for example, API functions provided by the driver, driver actions on changes in the operating system, etc.;

• Parameters that describe the environment of the driver, such as the software that uses the driver, the software that installed the driver, and so on.

In yet another implementation of the system, the driver 101 is considered dangerous if, as a result of the analysis, at least:

• security vulnerability in driver operation 101 ;

• potentially dangerous driver functionality 101 .

In another embodiment of the system, different detected security vulnerabilities in the operation of the driver 101 or potentially dangerous functions of the driver 101 are assigned different weights, on the basis of which the final risk factor of the driver 101 is then calculated.

In another embodiment of the method, a potentially dangerous functionality is a functionality that can be used hidden from the user and, at the same time, damage the performance of a computing device.

The search tool 130 is designed to search for the file 103 associated with the application 102 using the driver 101 .

In one system implementation, file 103 is associated with application 102 at least if:

• application 102 uses file 103 in its work;

• file 103 was created during the operation of application 102 ;

• application 102 was launched using file 103 .

In yet another implementation of the system, if the driver 101 hazard ratio calculated by the activity analyzer 120 exceeds a threshold value, a file 103 associated with the application 102 using the driver 101 is searched.

Malware Checker 140 is designed to:

• performing a check of the found file 103 for harmfulness;

• recognition of the found file 103 as malicious.

In one implementation of the system, the malware checker 140 is designed to recognize the file 103 as malicious as a result of an antivirus scan and make a decision about the harmfulness of the file 103 , taking into account the definition of the driver 101 as dangerous.

In yet another implementation of the system, anti-virus software can act as a means of checking for maliciousness 140 .

The quarantine tool 150 is designed to quarantine at least a driver 101 , an application 102 , or a file 103 .

In one of the options for implementing a quarantined system, the quarantined object is isolated, during which at least:

• removal of the found file 103 from the operating system;

• removal of the dangerous driver 101 from the operating system;

• removal of the application 102 , with which the found file 103 is associated, from the operating system;

• blocking (ie making it impossible for the operating system and other applications to use) a dangerous driver 101 , an application 102 with which the found file 103 is associated, a found file 103 .

In another embodiment of the system, anti-virus software acts as a means of quarantine 150 .

In another implementation of the system, the scheme for detecting a malicious file is implemented as follows:

After the finder 130 has found a file 103 associated with an application 102 using the driver 101 , such a file is considered suspicious (potentially dangerous) and quarantined using the quarantine tool 150 .

Then, using the malware checker 140, the quarantined file 103 found is checked for malware.

When a file 103 is found to be malicious, the quarantine tool 150 deletes the specified file 103 from the operating system.

In another embodiment of the system, similar actions are performed for at least:

• the application 102 with which the specified file 103 is associated;

• a driver 101 that uses the specified application 102 .

Fig. 2 is a block diagram of malicious file detection.

The block diagram of the malicious file detection method includes step 210 where API requests are intercepted, step 220 where driver activity is detected, step 230 where driver activity is analyzed, step 240 where the file is searched, step 250 where the file is checked for malware, step 260 where the file is quarantined.

The malicious file detection method is performed by means of the malicious file detection method system, which contains a processor and memory for this purpose and is described in more detail in FIG. 1 .

At step 210 , the interceptor 110 intercepts the API request of the driver 101 to the application 102 .

At step 220 , the interceptor 110 detects the activity of the driver 101 in the operating system by intercepting the API request of the driver 101 to the application 102 performed at step 210 .

In one embodiment, the method at step 220 detects the activity of the user-mode driver 101 with the help of another kernel-mode driver.

In another embodiment of the method, the activity of the driver 101 is at least:

• data transmission over a computer network;

• interaction with operating system services, including by calling API functions provided by the operating system;

• interaction with the application 102 running in the operating system, including by calling the corresponding API functions provided by the specified application 102 ;

• interaction with files or file structure, including interaction with the file 103 associated with the application 102 operating in the operating system, including by calling the appropriate API functions provided by the specified application 102 .

At step 230 , the activity analyzer 120 determines, based on the analysis of the driver 101 activity detected at step 220 , whether the driver 101 is dangerous.

In one of the embodiments of the method, as a result of the analysis of the activity of the driver 101, the hazard factor of the driver is determined and, if the hazard factor exceeds the threshold value, a search is made for the file 103 associated with the application 102 using the driver 101 , while the driver's hazard factor is a numerical value from a range, one end of which means a driver that is guaranteed to be harmless, and the other end is a driver that is guaranteed to be used to damage the computing device.

In another embodiment of the method, the analysis of the activity of the driver 101 consists in at least one of:

• identification of the analyzed driver 101 with a known driver from the database of dangerous drivers 121 ;

• simulation of the analyzed driver 101 in a virtual environment;

while the result of the analysis is the recognition of the analyzed driver 101 safe or dangerous.

In another variant of the method, the driver 101 is considered dangerous if, as a result of the analysis, at least:

• security vulnerability in driver operation 101 ;

• potentially dangerous driver functionality 101 .

In yet another embodiment of the method, a potentially dangerous functionality is a functionality that can be used hidden from the user and, at the same time, damage the performance of the computing device.

At step 240 , in the event that the driver 101 is found to be dangerous by the analysis performed at step 230 , the search engine 130 searches for the file 103 associated with the application 102 using the driver 101 .

At step 250 , the malware checker 140 recognizes the file 103 found at step 240 as malicious.

In one of the embodiments of the method, the found file 103 is recognized as malicious by means of a malware checker 140 as a result of an anti-virus scan and a decision is made on the harmfulness of the file 103 , taking into account the definition of the driver 101 as dangerous.

In yet another embodiment of the method, file 103 receives a higher hazard rating if it is used by a dangerous driver 101 compared to file 103 that is used by a safe driver.

In this case, such suspicious files will also be detected, which increases the accuracy of detecting malicious files.

In another embodiment of the method, after searching for the file 103 associated with the application 102 using the driver 101 , the malware checker 140 additionally checks the found file 103 for malware.

At step 260 , if the found file 103 is found to be malicious, the quarantine tool 150 additionally moves at least the driver 101 , application 102 or file 103 to quarantine.

In one of the options for implementing the quarantined method, the quarantined object is isolated, during which at least the following is carried out:

• removal of the found file 103 from the operating system;

• removal of the dangerous driver 101 from the operating system;

• removal of the application 102 , with which the found file 103 is associated, from the operating system;

• blocking (ie making it impossible for the operating system and other applications to use) a dangerous driver 101 , an application 102 with which the found file 103 is associated, a found file 103 .

Fig. 3 shows an example of a general purpose computer system, a personal computer or a server 20' , comprising a central processing unit 21' , system memory 22' , and a system bus 23' which contains various system components including memory associated with the central processing unit 21' . The system bus 23 is implemented as any bus structure known in the art, in turn comprising a bus memory or bus memory controller, a peripheral bus, and a local bus capable of interfacing with any other bus architecture. The system memory contains read-only memory (ROM) 24 , random access memory (RAM) 25 . The main input/output system (BIOS) 26 contains the basic procedures that ensure the transfer of information between the elements of a personal computer 20 , for example, at the time of booting the operating system using ROM 24 .

The personal computer 20, in turn, contains a hard disk 27 for reading and writing data, a magnetic disk drive 28 for reading and writing to removable magnetic disks 29 and an optical drive 30 for reading and writing to removable optical disks 31 , such as CD-ROM, DVD -ROM and other optical storage media. The hard disk 27 , the magnetic disk drive 28 , the optical drive 30 are connected to the system bus 23 via the hard disk interface 32 , the magnetic disk interface 33 , and the optical drive interface 34 , respectively. Drives and related computer storage media are non-volatile means of storing computer instructions, data structures, program modules, and other personal computer data 20 .

The present description discloses an implementation of a system that uses a hard disk 27 , a removable magnetic disk 29 and a removable optical disk 31 , but it should be understood that other types of computer storage media 56 that are capable of storing data in a computer-readable form (solid-state drives, flash memory cards, digital disks, random access memory (RAM) and the like) that are connected to the system bus 23 through the controller 55 .

The computer 20 has a file system 36 that stores the recorded operating system 35 as well as additional software applications 37 , other program modules 38 and program data 39 . The user has the ability to enter commands and information into the personal computer 20 through input devices (keyboard 40 , mouse 42 ). Other input devices (not shown) may be used: microphone, joystick, game console, scanner, etc. Such input devices are typically connected to the computer system 20 through a serial port 46 which is in turn connected to the system bus, but may be connected in other ways, such as through a parallel port, game port, or universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface such as a video adapter 48' . In addition to the monitor 47 , the personal computer may be equipped with other peripheral output devices (not shown), such as speakers, a printer, and the like.

The personal computer 20 is capable of operating in a networked environment using a network connection to another or more remote computers 49 . The remote computer (or computers) 49 are the same personal computers or servers that have most or all of the elements mentioned earlier in the description of the nature of the personal computer 20 shown in FIG. 3 . Other devices may also be present in the computer network, such as routers, network stations, peer-to-peer devices, or other network nodes.

The network connections may form a local area network (LAN) 50 and a wide area network (WAN). Such networks are used in corporate computer networks, internal networks of companies and, as a rule, have access to the Internet. In LAN or WAN networks, the personal computer 20 is connected to the local network 50 via a network adapter or network interface 51 . When using networks, personal computer 20 may use a modem 54 or other means to communicate with a wide area network, such as the Internet. Modem 54 , which is an internal or external device, is connected to system bus 23 via serial port 46 . It should be clarified that network connections are only exemplary and are not required to represent the exact configuration of the network, that is, in fact, there are other ways to establish a connection by technical means of communication from one computer to another.

In conclusion, it should be noted that the information given in the description are examples that do not limit the scope of the present invention defined by the formula.

Claims (21)

1. A computer-implemented method for detecting a malicious file, implemented on a computing device, including a processor and memory, with the help of which: • detect driver activity in the operating system by intercepting the driver's API request to the application; • determine the danger of the driver by analyzing the activity of the driver, where the analysis consists of at least one of: • identification of the analyzed driver with a known driver from the database of dangerous drivers; • simulating the operation of the analyzed driver in a virtual environment in order to detect a security vulnerability in the operation of the driver or potentially dangerous functionality of the driver; • if the driver is considered dangerous according to the results of the analysis, they search for the file associated with the application that uses the driver; • recognize the found file as malicious. 2. The method of claim 1, wherein step a) detects the activity of a driver running in user mode using another driver running in kernel mode. 3. The method according to claim 1, wherein the activity of the driver is at least: • data transmission over a computer network; • interaction with operating system services, including by calling API functions provided by the operating system; • interaction with an application running in the operating system, including by calling the corresponding API functions provided by the specified application; • interaction with a file or file structure, including interaction with a file associated with an application running in the operating system, including by calling the appropriate API functions provided by the specified application. 4. The method according to claim 1, according to which, as a result of the analysis of the driver's activity, the danger factor of the driver is determined and, if the danger factor exceeds the threshold value, the file associated with the application using the driver is searched. 5. The method according to claim 4, according to which the risk factor of the driver is a numerical value from the range, one border of which means a guaranteed non-dangerous driver, and the other border - a driver guaranteed to be used to damage the computing device. 6. The method according to claim 1, according to which a potentially dangerous functionality is a functionality that can be used hidden from the user and damage the performance of the computing device. 7. The method according to claim 1, according to which the found file is recognized as malicious as a result of an anti-virus scan and a decision is made on the harmfulness of the file, taking into account the definition of the driver as dangerous. 8. The method according to claim 1, according to which, after performing a search for a file associated with an application using the driver, the found file is additionally checked for maliciousness. 9. The method according to claim 1, according to which, if the found file is recognized as malicious, the found file is additionally quarantined and at least: • its removal from the operating system; • removal of a dangerous driver from the operating system.

Images