RU2673407C1 - System and method for identifying malicious files - Google Patents

Abstract

FIELD: information technology.SUBSTANCE: invention relates to computer security. This method for determining a malicious file in which at least the calls of API functions are recorded in the local call log of each computing device during the execution of the same files, during the execution of the file, the local log of calls for matching registered at least API function calls to behavioral rules from the local threat database is searched, in the case when no match to the behavioral rules is found, the local call log is transmitted to the detector, using the detection tool, the local call logs of the same files are combined into the combined call log, so that for each local call log, in the combined call log, there is at least one entry that is not in the local call log, entries from the combined call log matching at least one behavioral rule from the threat database are searched, when entries from the combined call log matching at least one behavioral rule from the threat database are found, the file is identified as malicious according to the found behavioral rule.EFFECT: improving the identification of a malicious file using behavioral rules.15 cl, 5 dwg

Description

Technical field

The invention relates to the field of computer security, and more particularly to systems and methods for determining malicious code.

State of the art

Traditional signature analysis does not always detect malicious files, especially polymorphic viruses, obfuscated (English obfuscated) files, as well as shell code (English shellcode, shell launch code).

Therefore, modern anti-virus applications additionally use a scan using the so-called “Sandboxes” (from the English “sandbox” - a specially allocated environment isolated from the rest of the system, restricting access and use of resources to the processes performed in it). A “sandbox” can be implemented, for example, in the form of a virtual machine, based on partial virtualization of the file system and registry, based on access rules to the file system and registry, or based on a mixed approach. The file being checked is executed in the sandbox. During the execution of the file, information about calls to API functions and system events is recorded in the call log. The anti-virus application further analyzes the received call log. The call log usually stores information about calls to API functions (English application programming interface, API) made by the mentioned file at runtime, as well as information about returns from called API functions (transfer of control to the return address). File execution in the sandbox usually occurs within a limited period of time (up to several tens of seconds). At the same time, when executing a file containing shellcode in the sandbox, it can be difficult to detect it by analyzing the API function call logs. Because the shell code could be loaded into the process memory, but the execution of the process in the sandbox stopped before the control had to be transferred to the piece of memory containing the shell code.

Another technology for detecting malicious code in a file is emulation, which consists in simulating the guest system while the code is running in the emulator.

In modern antiviruses, these technologies are used together. Usually, a signature analysis of the file is performed first, then, if no malicious behavior has been detected, the file is executed in an emulator or sandbox. If no malicious behavior was detected, the file will be executed directly on the user's computer (not in an isolated environment, as in the case of the sandbox). At this stage, another important antivirus module starts working - a behavioral analyzer that collects and analyzes the call log of API functions during the execution of the file on the user's computer. Using the installed driver-interceptors, the behavioral analyzer intercepts calls to API functions made during the execution of malicious code, as well as returns from the called API functions and stores them in the call log. The behavioral analyzer then searches the call log for patterns of known malicious behavior and issues a verdict (for example, a virus, a worm, a trojan, or conditionally unwanted software). The principle of analyzing the call log by the behavioral analyzer is similar to the work of the sandbox and the emulator. But the behavioral analyzer has no drawbacks inherent in the mentioned modules - there are no restrictions on the file execution time, the techniques for detecting and bypassing the emulator and the sandbox do not work, because the file is executed on the user's computer, and not in an isolated environment and not in the emulator.

But at the same time, the behavior of the file may differ depending on the runtime or even when running on the same computer with different input parameters. Thus, the behavior of the malicious file at each start may not fall under the known pattern of malicious behavior. The technical problem is the low definition quality of malicious files whose behavior does not fall within the known patterns of malicious behavior.

A known method for detecting malicious software in a real runtime (EP 3140732 A1). The method consists in registering the operations performed by the software in a log and in searching in this log for known patterns of malicious behavior. However, these methods do not allow to solve the claimed technical problem, i.e. it will not be able to identify a malicious file whose behavior does not fall within known patterns of malicious behavior.

Disclosure of the invention

The technical result consists in the implementation of the appointment.

The technical result consists in improving the quality of determining a malicious file using behavioral rules by searching for matching entries from the combined call log to at least one behavioral rule from the threat database, where the combined call log is obtained by combining different local call logs for the same files at least at least two computing devices.

According to an embodiment, a method for determining a malicious file is used, in which: using security tools operating on at least two computing devices, at least calls to API functions are recorded in the local call log of each computing device during the execution of identical files; on each computing device, using a protection tool, during file execution, a search is made in the local call log for correspondence of at least API function calls registered to the behavioral rules from the local threat database located on the computing device, while in the case when no compliance with behavioral rules, the security tool transmits the local call log to the detection tool located on the remote server; using the detection tool, combine local call logs of the same files received from at least two security means into a combined call log, so that for each local call log, the combined call log contains at least one entry that is not in the local call log using the detection tool, they search for matching records from the combined call log for at least one behavioral rule from the threat database, while the said threat database is located on the remote server and contains at least all the rules of the local threat database of each mentioned computing device; when matching records from the combined call log to at least one behavioral rule from the threat database, the file is determined to be malicious according to the found behavioral rule.

According to one particular embodiment, the following information is additionally recorded using security features, in particular, the following information: control transfer procedures to the return address from the API functions; Direct calls to Windows NT Native API functions Returns from Windows NT Native API Functions computer shutdown or reboot events; events in the operating system; indicators of compromise; system calls remedy verdicts; a checksum from a file or a checksum from a part of a file; the source of the file; file execution emulation results; the time the file appeared on the computing device; data received over the network by a file; data transmitted over the network by a file; spoofing a DNS server on a computer; disabling automatic updating of the operating system; disable the firewall; disable protection; disabling the "User Account Control" component; disabling the system recovery component of the system recovery; disabling the option “show hidden files, folders and drives” in the file manager; Change firewall rules Modify the hosts file deleting the file itself.

According to another particular embodiment, information similar to the one given above and associated with child processes and new files created by the said file is additionally recorded.

According to another particular embodiment, additionally, using the means of protection against targeted attacks, which is located on a separate remote server and connected via a computer network to at least one computing device, information related to the file is recorded in the local call log of said protection against targeted attacks executed on said computing device and passing through a computer network, after which the said local call log is transmitted to the caller fishing

According to one particular embodiment, using the means of protection against directed attacks, the following information is recorded, in particular: compromise indicators; remedy verdicts; a checksum from a file or a checksum from a part of a file; file download source to the computing device; data transmitted over the network by a file; data received over the network by a file; spoofing a DNS server on a computer.

According to an embodiment, a method for determining a malicious file is used, in which: from each of at least two security devices installed on different computing devices, local call logs that contain at least records of API function calls during the execution of identical files on each of said computing devices; combining said local call logs into a combined call log, so that for each local call log, the combined call log contains at least one entry that is not in the said local call log; using the detection tool, they search for matching records from the combined call log for at least one behavioral rule from the threat database; when matching records from the combined call log to at least one behavioral rule from the threat database, the file is determined to be malicious according to the found behavioral rule.

According to one particular embodiment, the following information is additionally recorded using security features, in particular, the following information: control transfer procedures to the return address from the API functions; Direct calls to Windows NT Native API functions Returns from Windows NT Native API Functions computer shutdown or reboot events; events in the operating system; indicators of compromise; system calls remedy verdicts; a checksum from a file or a checksum from a part of a file; the source of the file; file execution emulation results; the time the file appeared on the computing device; data received over the network by a file; data transmitted over the network by a file; spoofing a DNS server on a computer; disabling automatic updating of the operating system; disable the firewall; disable protection; disabling the "User Account Control" component; disabling the system recovery component of the system recovery; disabling the option “show hidden files, folders and drives” in the file manager; Change firewall rules Modify the hosts file deleting the file itself.

According to one particular embodiment, information similar to that given earlier and associated with child processes and new files created by the said file is additionally recorded.

According to another particular embodiment, a local call log is additionally obtained from means of protection against directed attacks, which is located on a separate remote server and is connected via a computer network to at least one computing device, said local call log containing information related to a file being executed on said computing device and passing through a computer network.

According to yet another particular embodiment, the local call log from the means of protection against directed attacks contains, in particular, the following information: indicators of compromise; remedy verdicts; a checksum from a file or a checksum from a part of a file; file download source to the computing device; data transmitted over the network by a file; data received over the network by a file; spoofing a DNS server on a computer.

According to an embodiment, a malicious file detection system is used, comprising: at least two computing devices, each of which contains a local threat database and a security tool is installed, using which: at least API calls are recorded in the local call log of each computing device functions at runtime of identical files; during the execution of the file, they search in the local call log for correspondence of at least API function calls registered to the behavioral rules from the local threat database located on the computing device; transmitting the local call log to the discovery tool located on the remote server in the case when no behavioral rule is found; a remote server containing a threat database, which contains at least all entries of the local threat database of each of the computing devices; detection tool associated with the threat database and intended for: combining local call logs of the same files received from at least two security means into a combined call log, so that for each local call log, the combined call log contains at least at least one entry that is not in the said local call log; search for matching entries from the combined call log to at least one behavioral rule from the threat database; determining the file as malicious when matching entries from the combined call log to at least one behavioral rule from the threat database.

According to one particular embodiment, the security features are additionally designed for registration, in particular, the following information: control transfer procedures to the return address from the API functions; Direct calls to Windows NT Native API functions Returns from Windows NT Native API Functions computer shutdown or reboot events; events in the operating system; indicators of compromise; system calls remedy verdicts; checksum of a file or its part; the source of the file; file execution emulation results; the time the file appeared on the computing device; data received over the network by a file; data transmitted over the network by a file; spoofing a DNS server on a computer; disabling automatic updating of the operating system; disable the firewall; disable protection; disabling the "User Account Control" component; disabling the system recovery component of the system recovery; disabling the option “show hidden files, folders and drives” in the file manager; Change firewall rules Modify the hosts file deleting the file itself.

According to one particular embodiment, the security measure is additionally designed to register information similar to that given earlier and associated with child processes and new files created by the said file.

According to another particular embodiment, the malicious file detection system further comprises a means of protection against targeted attacks, which is located on a separate remote server and is connected via a computer network to at least one computing device, and is designed to register the said means of protection against directed to a local call log attacks of information related to the file and passing through the computer network, as well as to transmit the said local log call detection means.

According to another particular embodiment, using the means of protection against directed attacks, the following information is recorded, in particular: compromise indicators; remedy verdicts; a checksum from a file or a checksum from a part of a file; file download source to the computing device; data transmitted over the network by a file; data received over the network by a file; spoofing a DNS server on a computer.

Brief Description of the Drawings

Additional objectives, features and advantages of the present invention will be apparent from reading the following description of an embodiment of the invention with reference to the accompanying drawings, in which:

In FIG. 1 is a schematic diagram of the present invention.

In FIG. Figure 2 shows a possible example of modules for the protection of a computing device.

In FIG. Figure 3 shows a possible example of protection against attack modules.

In FIG. 4 is a diagram of a method for determining a malicious file.

FIG. 5 is an example of a general purpose computer system.

The implementation 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, it can be embodied in various forms. The essence described in the description is nothing more than the specific details provided to assist the specialist in the field of technology in a comprehensive understanding of the invention, and the present invention is defined in the scope of the attached claims.

Glossary

Define a number of terms that will be used to describe embodiments of the invention.

Indicators of compromise (English indicator of compromise, US, less commonly infection indicators) - artifacts or residual signs of an intrusion into an information system, observed on a computer or on a network. Typical indicators of compromise are virus signatures, IP addresses, file checksums, URLs, domain names of botnet command centers, etc. There are a number of standards for indicators of compromise, in particular:

- OrenIOC (http://blogs.rsa.com/understanding-indicators-of-compromise-ioc-part-i/, http://openioc.org/),

- STIX (https://stix.mitre.org/),

- CybOX (https://cybox.mitre.org), etc.

A computer attack (also a cyber attack, from the English cyber attack) is a targeted impact on information systems and information and telecommunication networks by software and hardware, carried out in order to violate the security of information in these systems and networks (see. "The main directions of state policy in the field of ensuring security of automated control systems for production and technological processes of critical infrastructure of the Russian Federation ”(approved by the President of the Russian Federation 03.02.2012 N 803)).

Directed attack (also targeted or targeted attack, from the English targeted attack - TA) is a special case of a computer attack aimed at a specific organization or a specific individual.

Complex attacks (Advanced Persistent Threat - APT, also a developed persistent threat or also a targeted attack) - a complex, long-lasting, well-planned multi-path computer attack using sophisticated malicious software (software), social engineering methods and information about the information system of the attacked.

An inaccurate hash (English fuzzy hash) or flexible convolution (English locality sensitive hash) is a convolution of a file that is resistant to changes to the file by which it is generated. That is, when a malicious file is detected using the value of its convolution, a lot of similar (possibly unknown) malicious files will also be detected. The main feature of such a convolution is the invariance to small file changes. See, for example: RU 2580036, RU 2614561.

Inaccurate verdict - the operation of a protection tool (anti-virus application) when it detects suspicious actions during file execution that are characteristic of a malicious file. An inaccurate verdict is triggered, for example, when a file is detected using flexible convolution. An inaccurate verdict indicates that the file found is malicious with some probability.

In FIG. Figure 1 shows a computer system used to determine a malicious file using behavioral rules. The information system 100 (also the corporate infrastructure) includes a set of computing devices 101 (also, for brevity, computers) interconnected by a computer network 105. Computing devices 101 generally refer to any computing devices and sensors, in particular personal computers, laptops, smartphones, as well as communication devices such as routers, switches, hubs, etc. It is worth noting that computing device 101 can be like a physical device and virtual machine. The information system 100 can be organized using any topology of the network 105 known from the prior art, for example, one of the following types: fully connected, bus, star, ring, mesh, or mixed type. On the part of computing devices 101, protection devices for computing devices 102 are installed. It is worth noting that some computing devices 101 may not have security devices 102 installed. Information system 100 may include means of protection against targeted attacks 103, which can be located, for example, on a separate a remote server and is connected through a computer network 105 to at least one computing device 101. To connect computing devices 101 via a network 105 to the Internet and means about naruzheniya 110 can be used proxy servers (the figure is not shown).

In one particular implementation example, additional means of protection against targeted attacks 103 is designed to register in the local call log 109 information associated with said file, which is executed on said computing device 101 and passing through a computer network 105, in particular:

- indicators of compromise;

- verdicts of remedies (e.g. sandbox verdict, IDS);

- the checksum from the file or the checksum from the part of the file;

- the source for downloading the file to the computing device 101 (for example, the IP address of the source, the flash drive from which the file was downloaded to the computer, etc.);

- data transmitted over the network by a file (for example, what IP addresses are being accessed, what packets are transmitted, etc.);

- data received over the network by a file (for example, from which IP addresses are being accessed, which packets are transmitted, etc.);

- substitution of the DNS server on the computer.

The means of protection against directed attacks 103 is also intended to transmit a local call log 109 means of detection 110.

The system includes at least two computing devices 101 with security devices 102 operating on them. Security devices 102 register in the local call log 107 of each computing device 101 at least API function calls during the execution of the file under investigation (for example, the name of the function, parameters passed function call time).

In a particular embodiment, each entry of the local call log 107 about calls to API functions contains, in particular, the following information:

- name of the called function;

- a unique identifier of the process (process identifier, PID) launched from said file 134;

- a unique thread identifier (TID) that executes the instructions of the process address space;

- a set of arguments of the mentioned function;

- function call time.

The security tool 102, in the process of executing the file, searches the local call log 107 for the correspondence of at least registered API function calls to the behavioral rules from the local threat database 108. In a particular embodiment, the local call log 107 and the local threat database 108 are located on the computing device 101.

A behavioral rule includes information about calling at least one API function and a verdict (for example, a virus, a worm, a Trojan, or conditionally unwanted software) if this rule works. In a particular implementation example, behavioral rules consist, in particular, of a set of calls to API functions and logical expressions above them. For example, if certain API functions were called with specific parameters defined by a behavioral rule, then security tool 102 will find the rule in the call log 107.

The behavioral rule also corresponds to the verdict that is issued when this rule is triggered - that is, the most likely category of malware or unwanted software that the rule refers to. The verdict may be, for example, the following: a virus, a worm, a trojan, or conditionally unwanted software.

In a particular implementation example, behavioral rules include, but are not limited to:

- calling an API function from the list of suspicious API functions (for example, the list may contain the following API functions: WinExec, CreateProcess, GetFileSize, CreateFile);

- the GetFileSize API function call was made 10 times;

- after calling the WriteFile API function (writing to a file), a call to the WinExec API function (starting the file for execution) will follow;

- substitution of the DNS server on the computer;

- disabling automatic updating of the operating system;

- disable the firewall;

- disable protection;

- Disabling UAC (Eng. User Account Control, UAC - component of the Windows OS, User Account Control);

If the security tool 102 does not match the records of the local call log 107 to any behavioral rule from the local threat database 108, then the security tool 102 passes the local call log 107 to the detection tool 110 located on the remote server.

In a particular embodiment, the security tool 102 may transmit the local call log 107 to the detection tool 110 only if a behavior rule has been found that matches the malware verdict. In another example implementation, a local call log 107 will also be transmitted if a behavioral rule is found to which a conditionally unwanted software verdict matches.

Detector 110 combines the local call logs 107 received from at least two security means 102 into an integrated call log 116 located on a remote server for the analyzed file.

It is worth noting that the consolidation of local call logs 107 occurs when for each local call log 107, the aggregated call log 116 contains at least one entry that is not in the said local call log 107. Thus, the combined call log 116 is more complete than every single local call log 107.

To give an example, let there be three local call logs. The first log contains entries A, B, C, the second contains A, B, D, and the third contains A, C, D. In this example, a combined call log will be created containing the entries A, B, C, D. Moreover, for of each local call log 107, the combined call log 116 contains at least one entry that is not in the said local call log 107. Record D is not in the first log, record C is missing in the second log, and record B is in the third log.

To give one more example, let there be three local call logs. The first log contains entries A, B, the second - A, B, C, and the third - A, C. In this example, the combined call log will not be created, since it would contain entries A, B, C, and would coincide with the second a local journal (i.e., there would be no entries in the combined journal that are not in the second journal).

In one particular implementation example, the combined call log 116 will contain all the records of each local call log 107. In another particular implementation example, the combined call log 116 will contain all the records of one local call log 107 (for example, the first) and other local call logs 107, Missing in the first call log.

In a particular implementation example, the integration of local call logs 107 into a call log 116 occurs by combining the entries of the said local call logs 107. Moreover, overlapping entries may or may not be duplicated in the combined call log 116. In another example implementation, the local call logs 107 may further comprise a control flow graph (CFG) graph running from a file and, in this example, the combined call log 116 will contain the combined control flow graph detecting for said file obtained by combining several control-flow graphs.

Detector 110 searches for matching records from the unified call log 116 to at least one behavioral rule from the threat database 111. Moreover, the said threat database is located on the remote server and contains at least all entries of the local threat database 108 of each computing device 101 .

In FIG. Figure 2 shows a possible example of modules for a computing device protection. The security device of the computing device 102 may contain modules designed to ensure the security of the computing device 101: an access scanner, an on-demand scanner, mail antivirus, web antivirus, proactive protection module, HIPS module (Host Intrusion Prevention System - intrusion prevention system) , DLP module (data loss prevention), vulnerability scanner, emulator, firewall, etc. In a particular example implementation, these modules can be an integral part of security tool 102. In another example, p alizatsii these modules may be implemented as separate software components.

The access scanner contains functionality for detecting malicious activity of all opened, launched and saved files on the user's computer system. The on-demand scanner differs from the access scanner in that it scans user-specified files and directories on demand.

Mail antivirus is required to control incoming and outgoing e-mail regarding the contents of malicious files. Web antivirus is used to prevent the execution of malicious code that may be contained on websites hosted by the user, as well as to block the opening of websites. The HIPS module serves to detect unwanted and malicious activity of programs and block it at runtime. The DLP module is used to detect and prevent confidential data from leaking out of a computer or network. Vulnerability scanner is required to detect vulnerabilities on computing device 101 (for example, some components of protection tool 102, outdated virus databases are disabled, the network port is closed, etc.). The firewall monitors and filters network traffic in accordance with the specified rules. The emulator works by simulating the guest system while the code is running in the emulator. The proactive defense module uses behavioral signatures to detect the behavior of executable files and classify them by trust level.

When the detected modules detect malicious software (suspicious behavior, spam, and other signs of a computer threat), they create a corresponding notification (which can then be converted to the verdict of protection means 102), indicating to the protection means about the detected threat and the need to take actions to eliminate the threat ( for example, deleting or modifying a file, prohibition of execution, etc.). In a particular implementation example, the module itself, which detects malware, can perform actions to eliminate the threat. In another example, the verdict can be inaccurate or test (since this verdict can give false positives) - in this case, the security measure will not take action to eliminate the threat, but will send a notification to the detection tool 110. It should be noted that The security verdict 102 is part of the file information, which will then be transmitted to the detection tool 110 as a security notification. In a private embodiment, the malware includes the following categories (the verdict corresponds to the category) - malware and conditionally unwanted software. Malicious software can have subcategories - viruses, worms, trojans, packers, malware. Conditionally unwanted software is adware (Eng. Adware), software related to pornographic content (pornware), legal software that can harm your computer (riskware), etc.

In FIG. Figure 3 shows a possible example of protection against attack modules. The means of protection against targeted attacks 103 may contain, for example, the following protection modules: a sandbox, an intrusion detection system (IDS), a reputation service, a YARA rule checking module, and other detection modules.

The sandbox module has a functionality similar to the emulator of a security device of a computing device 102, with the difference that the sandbox can use additional computing power and work longer, since the protection against directed attacks 103 has no time limits inherent in a computing protection devices 102.

The sandbox is a computer environment for the safe execution of processes and is used to determine suspicious activity during the execution of a process launched from a file.

A sandbox can be implemented, for example, as a virtual machine, based on partial virtualization of the file system and registry, based on access rules to the file system and registry, or based on a mixed approach.

An intrusion detection system is a means of detecting unauthorized access to a computing device 101 or network 105 or unauthorized control thereof.

The reputation server may contain information about the popularity of files on computing devices 101 (the number of computing devices 101 on which the file is located, the number of file launches, etc.).

The YARA rule validation module is used to validate YARA signatures, an open signature format (see, http://yararules.com/).

The DLP module is used to detect and prevent confidential data from leaking out of a computer or network.

In FIG. 4 is a diagram of a method for determining a malicious file. So, in step 401, using protection means 102 operating on at least two computing devices 101, at least calls to API functions are recorded in the local call log 107 of each computing device 101 during the execution of identical files (i.e., on each computing device identical files are executed).

At the same time, computing devices 101 may have a different environment (operating system (OS) and its versions, installed OS updates, installed software and drivers, performed services and processes, the presence of an Internet connection, peripheral devices, etc.). In addition, the file (analyzed) can be opened for execution with various parameters depending on the computing device 101 or the opening time or other factors. Such parameters can be, for example, user rights (with administrator rights or user rights), a startup object (for example, an object or another file is transferred to the input file), with various startup keys (for example, the command "ie.exe -k "Windows command line interpreter" Cmd.exe "launches Internet Explorer in full screen mode) and others. Thus, during the execution of one file on different computing devices 101 (or even on one device), the file may have different behavior, make calls to various API functions, etc. For example, if there is no Internet connection on one computing device 101, the file will not be able to access the IP addresses that it can access when running on another computing device 101 that has an Internet connection.

At step 402, on each of the mentioned computing devices 101, using the protection means 102 (installed on the corresponding computing device 101), in the process of executing the file in the local call log 107, the correspondence of at least API function calls registered to the behavior rules from the local threat database is searched 108. If the protective equipment 102 has detected compliance with at least one behavioral rule, the file will be determined as malicious directly on the computing device 101 and further file execution will be completed by security tool 102.

Otherwise, in step 403, the security tool 102 will transmit the local call log 107 to the detection tool 110.

In step 404, the locating call logs 107 for the mentioned file are combined with the detection tool 110 into a combined call log 116. It should be noted that step 404 will be applicable when at least one entry is contained in each combined call log 107 in the combined call log 116 missing from said local call log 107.

At step 405, the detection tool 110 searches for matching records from the combined call log 116 to at least one behavioral rule from the threat database 111. In a particular embodiment, the local threat database 108 and threat database 111 are copies. In another particular embodiment, the threat database 111 contains at least all entries in the local threat database 108 and possibly other entries. For example, in order to save space on computing devices 101, local threat databases 108 may contain records of the most common threats that are specific to a given region, at a given time, or to a company-owner of information system 100. In another example, local databases threat data 108 is a mirror copy of the threat database 111 and is updated periodically. In this case, it is obvious that from the moment of the last update of the local threat database 108 and until the next scheduled update, the threat database 111 could be replenished with new threat records that are not in the local threat databases 108.

As a result, at step 406, if a match was found for entries from the unified call log 116 to at least one behavioral rule from the threat database 111, the file will be determined to be malicious according to the found behavioral rule. In this case, depending on the behavior rule found, at step 407, the detection tool 110 issue a verdict to a specific file (for example, a virus, a worm, a trojan, or conditionally unwanted software) and can create a virus signature for protection means 102. A virus signature is understood, for example , a signature for the signature analysis module of the security means 102 or an emulator signature.

Thus, the claimed technical problem will be solved - using the above method, a malicious file that was not detected by the protection means 102 will be detected. And a technical result will be achieved - the quality of determining a malicious file using behavior rules will be improved by searching for matching entries from the combined journal calls to at least one behavioral rule from the threat database, where the combined call log is obtained by combining different local call logs for duplicate files to at least two computing devices.

Here are a few examples of different behaviors during file execution on various computing devices 101 depending on their environment.

For example, if the file contains code for detecting and bypassing the emulator, then on the computing device 101 with the emulator working, the file can perform safe actions, while on the other computing device 101, on which the emulator is not working, the file will perform malicious actions.

In another example, a file can check the location of computing device 101 (for example, by OS localization) and perform various actions depending on location. In another example, during the execution of a file, malicious actions can be performed in relation to specific applications and corresponding verdicts are received, and if these applications are not installed on one computing device 101, then malicious actions will not be performed, verdicts will not be received.

In another example, a file may download additional malicious modules over the network, depending on the OS architecture (32-bit or 64-bit). In another example, a file can use various access channels to the command center - for example, through HTTPs, DNS, Twitter, Yandex. Disk or other access channels. In this case, on one computing device 101, the file can be accessed via HTTPs, and on the other via Twitter due to the fact that it was not possible to access via HTTPs.

In another example, a file running on the computing device 101 with administrator privileges may immediately begin to perform malicious activity. And when you run the same file on the computing device 101 without administrator rights, the file may try to increase its rights.

In a particular embodiment, with the help of the protective equipment 102, the following information is additionally recorded, in particular:

- procedures for transferring control to the return address from the API functions;

- direct calls to Windows NT Native API functions;

- returns from Windows NT Native API functions;

- events of shutting down or rebooting a computer system;

- system events of the operating system;

- indicators of compromise;

- system calls (for example, fopen (), create ());

- verdicts of a security measure (for example, a virus, a worm, a trojan, or conditionally unwanted software);

- the checksum from the file or the checksum from the part of the file;

- the source for downloading the file to the computing device 101 (for example, the IP address of the source, the flash drive from which the file was downloaded to the computer, etc.);

- Results of emulating file execution (emulator verdict);

- the time the file appeared on the computing device;

- data transmitted over the network by a file (for example, what IP addresses are being accessed, what packets are transmitted, etc.);

- data received over the network by a file (for example, from which IP addresses are being accessed, which packets are transmitted, etc.).

In another particular implementation example, with the help of the protection means 102, the following information is additionally recorded, in particular:

- substitution of the DNS server on the computer;

- disabling automatic updating of the operating system;

- disable the firewall;

- disable protection;

- Disabling the "User Account Control" component;

- disabling the component of the operating system "system recovery".

In yet another particular embodiment, with the aid of the security device 102, the following information is additionally recorded, in particular:

- disabling the option “show hidden files, folders and disks” in the file manager;

- change the rules of the firewall;

- changing the hosts file;

- deleting the file itself (for example, from a file being analyzed that is malicious, a process is performed that further injects the malicious code into the context of the svchost.exe system process and then deletes the file being analyzed);

- events of shutting down or rebooting a computer system;

- exceptional situations that occurred in the process;

- Obtaining addresses of system library descriptors (for example, kernel32.dll, ntdll.dll);

- memory allocation;

- reading system structures (Eng. process environment block - REV);

- sequential receipt of file descriptors.

In another particular embodiment, the above information is additionally recorded related to the child processes and new files that were created during the execution of the analyzed file.

In one particular implementation example, additionally, with the help of protection against targeted attacks 103, which is located on a separate remote server and connected via computer network 105 to at least one computing device 101, information is recorded in the local call log 109 of said protection against targeted attacks, associated with a file running on said computing device 101 and passing through a computer network, in particular:

- indicators of compromise;

- verdicts of remedies (e.g. sandbox verdict, IDS);

- the checksum from the file or the checksum from the part of the file;

- the source for downloading the file to the computing device 101 (for example, the IP address of the source, the flash drive from which the file was downloaded to the computer, etc.);

- data transmitted over the network by a file (for example, what IP addresses are being accessed, what packets are transmitted, etc.);

- data received over the network by a file (for example, from which IP addresses are being accessed, which packets are transmitted, etc.);

- substitution of the DNS server on the computer.

The targeted attack protection 103 in this embodiment further transfers the local call log 109 to the detection tool 110, which adds entries to the local call log 109 to the combined call log 116 in step 404.

In a particular embodiment, the protection against targeted attacks 103 may also be associated with a local threat database 112. In this case, the protection against targeted attacks 103 may search for compliance of entries in the local call log 109 with the behavioral rules from the local threat database 112. If at least one behavioral rule is found, the file can be determined malicious, an appropriate verdict will be issued and a notification will be sent to the protection means 102, located Nome on the computing device 101 on which the said file. After that, the protection tool 102 will take the necessary steps to eliminate the file identified by the malware. If the means of protection against targeted attacks 103 does not reveal compliance with any of the behavioral rules, then the local call log 109 will be passed to the detection tool 110 in step 403.

In a particular implementation example, the local call log 109, as well as the local threat database 112, are located on the same remote server where the protection against targeted attacks 103 is located.

In a particular embodiment, the local threat database 112 and the threat database 111 are copies. In another particular embodiment, the threat database 111 contains at least all entries in the local threat database 112 and possibly other entries.

FIG. 5 is an example of a general purpose computer system, a personal computer or server 20 comprising a central processor 21, a system memory 22, and a system bus 23 that contains various system components, including memory associated with the central processor 21. The system bus 23 is implemented as any prior art bus structure comprising, in turn, a bus memory or a bus memory controller, a peripheral bus and a local bus that is capable of interacting 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 basic procedures that ensure the transfer of information between the elements of the personal computer 20, for example, at the time of loading the operating ROM systems 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 a CD-ROM, DVD -ROM and other optical information carriers. The hard disk 27, the magnetic disk drive 28, the optical drive 30 are connected to the system bus 23 through the interface of the hard disk 32, the interface of the magnetic disks 33 and the interface of the optical drive 34, respectively. Drives and associated computer storage media are non-volatile means of storing computer instructions, data structures, software modules and other data of a personal computer 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 can store data in a form readable by a computer (solid state drives, flash memory cards, digital disks, random access memory (RAM), etc.) that are connected to the system bus 23 through the controller 55.

Computer 20 has a file system 36 where the recorded operating system 35 is stored, as well as additional software applications 37, other program modules 38, and program data 39. The user is able to enter commands and information into personal computer 20 via input devices (keyboard 40, keypad “ the mouse "42). Other input devices (not displayed) can be used: microphone, joystick, game console, scanner, etc. Similar input devices are, as usual, connected to computer system 20 via serial port 46, which in turn is connected to the system bus, but can be connected in another way, for example, using a parallel port, a 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 can be equipped with other peripheral output devices (not displayed), for example, speakers, a printer, etc. .

The personal computer 20 is capable of operating in a networked environment, using a network connection with 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 creature the personal computer 20 of FIG. 5. Other devices, such as routers, network stations, peer-to-peer devices, or other network nodes, may also be present on the computer network.

Network connections can form a local area network (LAN) 50 and a wide area network (WAN). Such networks are used in corporate computer networks (also - information systems), 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 area network 50 via a network adapter or network interface 51. When using the networks, the personal computer 20 may use a modem 54 or other means of providing communication with a global computer network such as the Internet. The modem 54, which is an internal or external device, is connected to the system bus 23 via the serial port 46. It should be clarified that the network connections are only exemplary and are not required to display the exact network configuration, i.e. in reality, there are other ways to establish a technical connection between one computer and another.

In accordance with the description, components, execution steps, data structure described above can be performed using various types of operating systems, computer platforms, programs.

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

Claims (126)

1. A method for determining a malicious file, in which: a) using security tools operating on at least two computing devices, register at least calls to API functions during the execution of identical files in the local call log of each computing device; b) on each computing device, using a security tool, during file execution, a search is made in the local call log for correspondence of at least API function calls registered to the behavioral rules from the local threat database located on the computing device, while in case it is not found no compliance with the behavioral rules, the security tool transmits the local call log to the detection tool located on the remote server; c) using the detection tool, combine local call logs of the same files received from at least two security means into a combined call log, so that for each local call log, the combined call log contains at least one entry that is not in said local call log; d) using the detection tool, search for matching records from the combined call log to at least one behavioral rule from the threat database, while the said threat database is located on the remote server and contains at least all the rules of the local threat database of each mentioned computing device ; e) when matching records from the combined call log to at least one behavioral rule from the threat database, the file is determined to be malicious according to the found behavioral rule. 2. The method according to p. 1, in which with the help of protective equipment additionally register, in particular, the following information: - procedures for transferring control to the return address from the API functions; - direct calls to Windows NT Native API functions; - returns from Windows NT Native API functions; - events of shutting down or rebooting a computer system; - events in the operating system; - indicators of compromise; - system calls; - verdicts of a remedy; - the checksum from the file or the checksum from the part of the file; - the source of the file; - results of emulating file execution; - the time the file appeared on the computing device; - data received over the network by a file; - data transmitted over the network by a file; - substitution of the DNS server on the computer; - disabling automatic updating of the operating system; - disable the firewall; - disable protection; - Disabling the "User Account Control" component; - disabling the component of the operating system "system recovery"; - disabling the option “show hidden files, folders and disks” in the file manager; - change the rules of the firewall; - changing the hosts file; - deleting the file itself. 3. The method according to p. 2, in which additionally register information similar to that given in p. 2 and associated with child processes and new files created by the file. 4. The method according to p. 1, in which additionally using the means of protection against directed attacks, which is located on a separate remote server and connected via a computer network to at least one computing device, register information in the local call log of said means of protection against directed attacks associated with a file running on said computing device and passing through a computer network, after which said local call log is transmitted to the detection means. 5. The method according to p. 4, in which using the means of protection against directed attacks register, in particular, the following information: - indicators of compromise; - verdicts of a remedy; - the checksum from the file or the checksum from the part of the file; - the source of the file download to the computing device; - data transmitted over the network by a file; - data received over the network by a file; - substitution of the DNS server on the computer. 6. A method for determining a malicious file, in which: a) receive from each of at least two security devices installed on different computing devices local call logs that contain at least records of calls to API functions during the execution of identical files on each of the mentioned computing devices; b) combine said local call logs into a combined call log, so that for each local call log, the combined call log contains at least one entry that is not in the said local call log; c) using the detection tool, search for matching records from the combined call log for at least one behavioral rule from the threat database; d) when matching entries from the combined call log to at least one behavioral rule from the threat database, the file is determined to be malicious according to the found behavioral rule. 7. The method according to p. 6, in which with the help of protective equipment additionally register, in particular, the following information: - procedures for transferring control to the return address from the API functions; - direct calls to Windows NT Native API functions; - returns from Windows NT Native API functions; - events of shutting down or rebooting a computer system; - events in the operating system; - indicators of compromise; - system calls; - verdicts of a remedy; - the checksum from the file or the checksum from the part of the file; - the source of the file; - results of emulating file execution; - the time the file appeared on the computing device; - data received over the network by a file; - data transmitted over the network by a file; - substitution of the DNS server on the computer; - disabling automatic updating of the operating system; - disable the firewall; - disable protection; - Disabling the "User Account Control" component; - disabling the component of the operating system "system recovery"; - disabling the option “show hidden files, folders and disks” in the file manager; - change the rules of the firewall; - changing the hosts file; - deleting the file itself. 8. The method according to p. 7, in which additionally register information similar to that given in p. 7 and associated with child processes and new files created by the file. 9. The method according to p. 7, in which at step a) additionally receive a local call log from means of protection against directed attacks, which is located on a separate remote server and connected via a computer network to at least one computing device, said local log The call contains information related to a file running on said computing device and passing through a computer network. 10. The method according to p. 9, in which the local call log from the means of protection against directed attacks contains, in particular, the following information: - indicators of compromise; - verdicts of a remedy; - the checksum from the file or the checksum from the part of the file; - the source of the file download to the computing device; - data transmitted over the network by a file; - data received over the network by a file; - substitution of the DNS server on the computer. 11. A malware detection system, comprising: a) at least two computing devices, each of which contains a local database of threats and a security tool is installed, using which: - register at least calls to API functions during execution of identical files in the local call log of each computing device; - during the execution of the file, a search is performed in the local call log for correspondence of at least API function calls registered to the behavioral rules from the local threat database located on the computing device; - transmit the local call log to the detection tool located on the remote server in the case when no behavior rules are found; b) a remote server containing a threat database that contains at least all entries of the local threat database of each computing device mentioned; c) a detection tool associated with the threat database and designed to: - combining local call logs of the same files received from at least two security means into a combined call log, so that for each local call log, the combined call log contains at least one entry that is not in the said local call log; - search for matching entries from the combined call log to at least one behavioral rule from the threat database; - determining the file as malicious when matching entries from the combined call log to at least one behavioral rule from the threat database. 12. The system according to claim 11, in which the protective equipment is additionally intended for registration, in particular, the following information: - procedures for transferring control to the return address from the API functions; - direct calls to Windows NT Native API functions; - returns from Windows NT Native API functions; - events of shutting down or rebooting a computer system; - events in the operating system; - indicators of compromise; - system calls; - verdicts of a remedy; - the checksum of the file or its part; - the source of the file; - results of emulating file execution; - the time the file appeared on the computing device; - data received over the network by a file; - data transmitted over the network by a file; - substitution of the DNS server on the computer; - disabling automatic updating of the operating system; - disable the firewall; - disable protection; - Disabling the "User Account Control" component; - disabling the component of the operating system "system recovery"; - disabling the option “show hidden files, folders and disks” in the file manager; - change the rules of the firewall; - changing the hosts file; - deleting the file itself. 13. The system of claim 12, wherein the security measure is further designed to record information similar to that described in paragraph 12 and associated with child processes and new files created by said file. 14. The system of claim 11, further comprising a means of protection against directed attacks, which is located on a separate remote server and is connected via a computer network to at least one computing device, and is intended for registration in a local call log of said means of protection against directed attacks information associated with said file and passing through the computer network, as well as for transmitting said local call log to the detection means. 15. The system according to p. 14, in which using the means of protection against directed attacks register, in particular, the following information: - indicators of compromise; - verdicts of a remedy; - the checksum from the file or the checksum from the part of the file; - the source of the file download to the computing device; - data transmitted over the network by a file; - data received over the network by a file; - substitution of the DNS server on the computer.

Images