RU2649794C1 - System and method for log forming in virtual machine for anti-virus file checking - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: invention relates to solutions for detecting malicious files. Method for deciding to recognize malicious file opened in virtual machine as environment for safe execution of files is disclosed, at that method comprises steps, when: a) during process flow created when file is opened, occurrence of event that is associated with change in at least one page of virtual memory is detected; b) during execution of process flow created when opening file, control transfer to at least one modified virtual memory page is detected; c) log to which following events are saved is created: events that occur during process stream, created when file is opened in modified memory page, and context of processor on which process flow, created when file is opened, is read when logged event occurs; d) saved events in created log are compared with processor context with at least one template; e) it is decided whether to recognize file as malicious, based on comparison results.

EFFECT: technical result is to increase security of computer system, which is achieved by deciding whether to recognize malicious file opened in virtual machine.

8 cl, 4 dwg

Description

Technical field

The invention relates to solutions for detecting malicious files, and more particularly to systems and methods for generating a log for anti-virus scanning of a file.

State of the art

Currently, an increasing number of malicious software (for example, computer viruses, trojans, network worms), aimed at causing damage to both user data and the user of an electronic device infected with malware. Damage can be caused by damage or deletion of the user's files, using the resources of the user's computing device for the “mining” of cryptocurrencies, the theft of electronic and confidential user data (correspondence, images, logins, passwords, bank card data) and other actions. In addition, malicious software is constantly changing, as its authors resort to increasingly new attack mechanisms and protection from security applications. Various mechanisms are used, for example, obfuscation (in other words, bringing the source code or executable code of a program to a form that preserves its functionality, but makes it difficult to analyze, understand the operation algorithms and modify when decompiling, for example) malicious code or using anti-emulation mechanisms (for example, malicious software the software is endowed with the functions of recognizing that it is executed in the emulator and does not show its malicious activity).

In addition, often malicious software does not show its malicious activity immediately, instead, it makes many (about millions of calls) calls to API functions, huge cycles (about billions of iterations), pauses for some time immediately after launch (for example, 1 hour using the Sleep () function). The user's computing devices currently have high performance, multi-core processors (there are also multi-processor systems), so the user may not see or attach importance to the load on one of the cores. In addition, the user usually uses the device after turning it on for more than one hour. Therefore, malicious software, if it starts, there is no need to immediately show their activity.

To combat the mentioned approaches, manufacturers of security applications (for example, anti-virus applications) use approaches using virtual machines as an isolated environment for the safe execution of files. Often such virtual machines are called sandboxes (from the English sandbox). Hypervisors under the control of which such virtual machines operate contain mechanisms for intercepting functions caused by applications executed in them.

It is worth noting that security applications use various methods for detecting malicious software, for example, technologies such as signature and / or heuristic analysis. If the maliciousness of the file was not determined during the analysis, it can be sent by the security application for analysis of the behavior to the mentioned virtual machine (for example, if it does not have a digital signature of a trusted software manufacturer). Then the transferred file is executed in a virtual machine, in the process of execution, its actions and events are intercepted, executed by calls of various functions, intercepted events and actions are stored in a log and further analyzed by a security application or information security expert.

Thus, the well-known systems for intercepting and aggregating events and actions work in two steps. At the first step, information is collected, at the second it is analyzed.

So, publication US 8479286 B2 describes a system and method in which a file is analyzed before being executed in a virtual machine, and the environment that is most suitable for revealing the file’s behavior is selected based on the analysis results to execute the file. Next, the file is executed, if according to the results of the decision to change the environment, the environment is changed, and the file is executed again.

Publication US 7779472 B1 describes a classic way to execute a file in a virtual machine. During execution, calls to API functions and their parameters are intercepted. The set of called API functions is compared with sets of calls that correspond to malicious behavior. In case of compliance, a decision is made on the harmfulness of the file.

A disadvantage of the known systems and methods is that during the execution of the file they do not affect the execution process. For example, if a process started from the analyzed file (or from the application with which the analyzed file was opened) has suspended for an hour or is attacked by any mail client or messenger (messaging program), accessing the file with saved passwords, but the attacked program is absent in the virtual machine, the malicious behavior of the file will not be detected (since, if the required file with passwords is not detected, the malicious file will finish its execution itself and will not show malicious activity).

The present invention allows you to influence the process of executing a file in a virtual machine when analyzing a file for malware.

SUMMARY OF THE INVENTION

The technical result of the present invention is to improve the security of a computer system, which is achieved by deciding whether to recognize a file opened in a virtual machine as malicious.

According to one embodiment, a method is provided for deciding whether a file is opened in a virtual machine as an environment for the safe execution of files as malicious, the method comprising the steps of: identifying, during execution of a process thread created when the file was opened, the occurrence of an event which is associated with changing at least one page of virtual memory; during execution of a process thread created when opening said file is detected, control transfer to at least one modified page of virtual memory; form a log in which they save: events that occur during the execution of the process thread created when the mentioned file was opened in the modified memory page, and the processor context read on the event log stored in the event occurs, on which the thread of the process created when the mentioned file was opened is executed; comparing the events stored in the generated log and the processor context with at least one template; make a decision to recognize the file as malicious based on the results of the comparison.

According to another particular embodiment, a method is proposed in which an event associated with a change in a memory page is a call to an API function during execution of a process thread.

According to yet another particular embodiment, a method is provided in which, when determining a changed memory page, an identifier of the changed page is detected.

According to another particular embodiment, a method is proposed in which a control transfer to a changed memory page is detected if the thread executing the code from the changed page is launched from the same process as the thread that changed the memory page.

According to another particular embodiment, a method is proposed in which a control transfer to a changed memory page is detected if the thread executing the code from the modified page is started from a process other than the process whose thread changed the memory page.

According to yet another particular embodiment, a method is provided in which the template contains at least one rule.

According to yet another particular embodiment, a method is provided in which the rule comprises at least one event.

According to yet another particular embodiment, a method is provided in which the rule comprises at least one processor context.

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:

FIG. 1 shows an example of a malware file analysis in a virtual machine.

FIG. 2 shows an example of the implementation of the proposed log generation system for anti-virus file scanning.

FIG. 3 shows an example implementation of the proposed method for generating a log for anti-virus scanning of a file.

FIG. 4 shows an example of a general purpose computer system that enables the implementation of the present invention.

Description of Embodiments

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 only in the scope of the attached claims.

We introduce a number of definitions and concepts that will be used in the description of embodiments of the invention.

A virtual machine in the form of an environment for safe file execution is a set (complex) of hardware and software that provides the resources of the host operating system (GOST 56938-2016) for the guest operating system, while the guest operating system does not have a connection with the host operating system.

By the means of a malware analysis system file in a virtual machine, the present invention refers to real devices, systems, components, groups of components implemented using hardware such as integrated circuits (application-specific integrated circuit, ASIC) or programmable gate arrays ( field-programmable gate array (FPGA) or, for example, as a combination of software and hardware, such as a microprocessor system and a set of software instructions, as well as on neuromorphic chips (English neurosynaptic chips) Fu The functionality of the indicated system tools can be implemented exclusively by hardware, as well as in the form of a combination, where part of the functionality of the system tools is implemented by software, and part by hardware. In some embodiments, part of the means, or all means, may be executed on a general-purpose computer processor (for example, which is depicted in Fig. 4). In this case, the components (each of the means) of the system can be implemented within the framework of a single computing device, or distributed between several connected computing devices.

FIG. 1 shows an example of a malware file analysis in a virtual machine.

In general, for malware analysis, file 100 is opened in virtual machine 120 as an isolated environment for executing files. Security tool 110 transmits file 100 to virtual machine 120. In one embodiment, virtual machine 120 is created by security tool 110. In another embodiment, virtual machine 120 is selected by security tool 110 from previously created virtual machines.

It is worth noting that in the framework of the present invention, file 100 is:

- executable file;

- dynamic library;

- a script executed by an interpreter (for example, Microsoft PowerShell files);

- files containing execution scripts (for example, Microsoft Office or Adobe Acrobat file formats);

- webpage;

- image;

- other files known from the prior art that, when used (for example, when executed or opened by other applications), can harm the user data of the computing device.

In one embodiment, a file 100 is a link (for example, a URL).

In the General case, the analysis of the file 100 is carried out after it is opened in the operating system of the virtual machine 120. By opening the file 100 is meant one of:

- execution of file 100, if file 100 is executable;

- opening the file 100 by the application if the file 100 is not executable.

The result of opening the file 100 is the creation and execution of a process (Eng. Process) in the virtual machine 120. This creates at least one thread (Eng. Thread).

In one embodiment, the security tool 110 and the virtual machine monitor 115 (hereinafter referred to as the hypervisor), under the control of which the virtual machine 120 is running, are executed on the user's computing device. In this case, security tool 110 is a security application (e.g., an anti-virus application). In another case, the security tool 110 and the hypervisor 115 are executed on a remote server (or on different servers) or as a cloud service. In this case, the security tool 110 receives the file 100 from third-party sources (for example, from the security tools 110 operating on the user's computing devices) and transfers it to the virtual machine 120, where the file 100 is opened.

In general, the hypervisor 115 comprises interception means 130 (the interception means 130 is a module, component, or functional part of the hypervisor 115). The interceptor 130 intercepts the calls to the API functions by the threads of the process created when the file 100 was opened in the virtual machine 120, reads the context of the processor on which the thread that called the API function is executed. It is worth noting that the processor context contains at least the values of the processor registers. In one embodiment, the interceptor 130 also reads the stack using previously read data contained in processor registers corresponding to the stack (for example, memory at an address from ESP and EBP registers). In addition, the interception tool 130 aggregates the mentioned data, saves it (for example, in the database or in the log 150) and transfers it to the security tool 110 after executing the process created when the file 100 was opened. The security tool 110, in turn, makes based on data means of interception 130 verdict on the harmfulness of the file 100. In general, a verdict is issued after analyzing the stored data, for example, depending on in what sequence and with what parameters the API functions were called by process threads, created this when opening the file 100. In one embodiment, if the verdict has not been issued, the data stored by the interceptor 130 is transmitted by the security tool 110 to the information security specialist (not shown in Fig. 1) for analysis.

FIG. 2 shows an example of the implementation of the proposed log generation system for anti-virus file scanning.

The present invention is characterized in that the proposed system along with interception means 130 also contains analysis means 140. In one embodiment, the hypervisor 115 contains analysis means 140. In another embodiment, the analysis means 140 is a component (module, functional part) of the security means 110.

In general, the interceptor 130 intercepts events in the threads of the process created when the file 100 was opened.

Events are at least:

- call the API function by the thread;

- return from the API function;

- a system call or, in other words, a thread accessing the kernel of the operating system to perform an operation (English system call);

- return from a system call;

- notification (notification, notification) from the operating system (for example, creating a thread, creating a process, loading a module).

In the event of an event interception, the execution of the stream is suspended by the interception means 130. It should be noted that interception is possible on different protection rings of the operating system of the virtual machine 120, which implement hardware separation of the system and user privilege levels, which ensures interception of events on:

- kernel level (English kernel mode),

- application level (English user mode).

Stream execution is paused by stopping the execution of stream instructions.

It is worth noting that in the general case of the implementation, during the execution of the threads of the process created when the file 100 was opened, the interception tool 130 defines the coding standard (called coding convention) of the API functions called by the threads. This allows you to uniquely determine the use of processor registers for passing parameters to the called API functions. So, for example, the call parameters will be in the ECX registers (first parameter), EDX (second parameter), the remaining parameters will be on the stack (ESP register). In addition, the coding standard allows you to uniquely determine the return value. For example, if the API function returns the value “0”, it does so in the EAX register.

The intercepted event and the processor context are captured by the interceptor in the log 150. After being saved, the log 150 is transmitted by the interceptor 130 to the analyzer 140.

Analysis Tool 140 uses a set of patterns. In one embodiment, the templates are stored in a data structure (for example, in a tree). Templates can be added to the data structure by analysis tool 140 during startup of virtual machine 120. In another implementation, templates are selected by analysis tool 140 from the database.

In general, a template contains one or more rules. In one embodiment, each rule is assigned a priority. Otherwise, the rules are added to the template in an orderly manner.

A rule is a logical condition based on the use of logical operands (for example, “if” or “logical or”). In addition, the rules may be related to each other. In one implementation, the rule uses the stored processor context. In another embodiment, the rule contains logic for changing the context of the processor and data for changing the context of the processor. In yet another implementation, the rule contains logic by which the analysis tool 140 recognizes the open file 100 as malicious.

Examples of the above rules are:

Rule 1: “if” is called by FileOpen (“$ SytemDrive: \ <random name>”), “then” continue execution.

Rule 2: “if” Rule 1 and FileWrite (“$ SytemDrive: \ <random name>”, text string), “then” continue execution.

In the above example, the thread of the process created when opening the file 100 accesses a random (required) file in the root of the system disk. The event of creating (or reading) the required file in itself is not malicious, but it is often the beginning of malicious functionality. Therefore, analysis tool 140, based on the rules, makes a decision to continue execution of said stream. Next, the required file is recorded. Depending on the type of the required file and the information recorded in it, the required file may have malicious functionality.

A more detailed example of how the system and rules work is the following set:

Rule 10: “if” file 100 is not signed, then continue execution.

Rule 11: “if” rule 10, “and” file 100 called FileOpen (“$ SytemDrive: \ <random name>”), “then” replace the return value with “Success” “and” continue execution.

Rule 12: “if” rule 11, “and” file 100 caused FileWrite (“$ SytemDrive: \ <random name>”, the memory buffer used by the process created when opening file 100), “then” recognize file 100 as malicious “and »Finish the execution.

It should be noted that in the above example of the rules, “file 100” is used for a more visual and understandable presentation of the rules. In the general case, the rule uses the threads of the process created when the file 100 was opened.

In the above example, the file 100 is not signed, that is, the provider (creator) of the file 100 is unknown. Further, the flow of the process created when opening the file 100, in the process of execution also refers to a random file in the root of the system drive. However, usually the operating system prohibits the creation of a file in the root of the system drive (malicious files may check other paths until the file is created). Therefore, the analysis tool 140, based on the rules, makes the decision to replace the returned result with “success”, using the interception tool 130, the result is changed, then the execution of the process flow created when the file 100 is opened continues. Next, a record is created in the created file. If a memory buffer is written to the created file, the file may be malicious (have malicious functionality). It makes sense to stop analyzing file 100, then analyze the created file, and, based on the analysis of the created file, render a verdict on the harmfulness of file 100.

It is worth noting that the above are only examples of rules. In general, the rules can be more capacious, for example, monitor the creation of a file in different ways, monitor the extension of the created file, analyze the type of the created file, allow the creation of the file and monitor the further behavior of the threads of the process created when the file was opened 100 (for example, will there be any attempts add the created file to the startup list of the operating system in any known way), track the change of attributes by the streams of both file 100 and other files, track the access of streams to the Internet.

In one embodiment, the analysis tool 140 also operates with expert data (expertise) that is stored in a separate database. This data can also be used in template rules.

An example of such a rule may be:

Rule 21: “if” file 100 refers to the web resource, “and” the web resource is assigned a malicious category, “then” recognize file 100 as malicious.

It is worth noting that in the above example, the category of the web resource accessed by the flow of the process created when the file 100 was opened in the virtual machine was previously defined (assigned) in a manner known from the level and stored in a separate database.

In one embodiment, the rule contains a condition for the depth of analysis or the depth of event aggregation. For example,

Rule 31: “if” the file 100 executes a loop, “and” the context of the events of invoking API functions does not change, “then” do not intercept return events from API functions.

This example rule allows you to speed up the execution of file 100 by reducing the number of event hooks and reading context. If a thread of the order of one billion iterations consisting of calls “CreateWindow ()”, “CloseWindow ()” was called by the flow of the process created when opening file 100, it makes no sense to intercept and save the context of each event. Obviously, the interceptor 130, in accordance with the above, will work at least four billion times (two API functions are called in a loop, the event is a call and return from the API function), and it will read the processor context the same number of times.

In one embodiment, the rule contains a condition for increasing the loop variable. For example,

Rule 41: “if” file 100 executes a loop, “and” the context of events for invoking API functions does not change, “then” increase the value of the loop variable 5 times every 10 iterations.

The above example is applicable to speed up the execution of cycles by a process thread created when file 100 was opened in virtual machine 120. Analysis tool 140 determines that an executable thread cyclically triggers some events. However, nothing happens, which is one of the well-known anti-emulation scenarios. In order for the flow of the process created when opening the file 100 to show its full functionality, it is necessary to complete the cycle as soon as possible and continue execution. Thanks to the above rule, the cycle will be completed several times faster.

In one embodiment, the interception tool 130 detects when the process thread created when opening the file 100 is executed, the occurrence of an event that is associated with a change in the virtual memory page (hereinafter referred to as the memory page). In the general case, the event associated with a change in the memory page is a call to an API function by a thread. Changing data in a memory page can occur either directly, for example, by calling WriteProcessMemory (), or hidden, for example, by writing data using SetWindowLong (). In this case, you can identify, for example, the handle (English handle) of the window. It is worth noting that writing to the memory of another process is a completely legal operation from the point of view of the operating system. But malware also very often uses similar mechanisms to inject malicious code. The events associated with the change of the pages of memory, and the processor context, the interceptor 130 stores in the log 150.

An analysis tool 140 determines modified pages of memory. According to the analysis of the log 150, in which the events associated with the change of the memory pages and the processor context are stored, by means of the analysis 140 identifiers (for example, addresses or numbers) of the modified memory pages can be detected.

In one embodiment, the analyzer 140 passes the identifiers of the modified pages to the interceptor 130.

The interceptor 130 also detects the transfer of control to any of the modified pages, the identifiers of which are obtained from the analysis tool 140. Transfer of control to a memory page generally means that the thread executes code at the virtual address that is contained on this memory page. In one embodiment, control transfer is detected if the thread executing the code from the modified page is launched from the same process as the thread that changed the memory page. In another embodiment, the control transfer is detected if the thread executing the code from the modified page is started from a process other than the process whose thread changed the memory page. Thus, if the memory page was changed by the thread of the process created when the file 100 was opened, and it belongs to the same (changing its own memory pages is used by malicious applications as protection against signature analysis or preventing static analysis of executable code) or another process (for example, explorer.exe), it is necessary to intercept process events when control is transferred to the modified memory page.

In the General case, after the transfer of control to the modified memory page, the interception tool 130 and the analysis tool 140 perform the above operations.

An example of the above is

Rule 51: “if” the process created when opening the file 100 changes data in at least one memory page, “then” intercept events when transferring control to at least one of the pages on which the data was changed.

This approach saves system resources when analyzing applications that change the memory pages of other applications. For example, the anti-emulation scenarios mentioned above are not analyzed (many calls to API functions that are not harmful to user data), the analysis tool 130 does not save every call in the log 150. In this case, it analyzes only whether control will be transferred to the modified memory pages and whether the code in said modified virtual memory pages is malicious. Only the events that change the pages of memory and the events that occur when the code is executed from the modified pages of the memory get into the journal 150 formed in this way by the interception 130.

Thus, the analysis tool 140 after receiving the log 150 from the interception tool 130 analyzes the events that have occurred, that is, the events (current and previous) stored in the log 150, and the data of the events that have occurred (for example, the processor context corresponding to any event). The analysis consists in comparing the events that have occurred with the template. In this case, the event is compared sequentially with each rule stored in the template (depending on the order of the rules in the template or their priority). Based on the comparison, the analysis tool 140 makes at least one of the decisions:

- decision to recognize the file 100 as malicious;

- the decision to stop the execution of the process created when opening the file 100;

- a decision to change the context of the processor;

- The decision to wait for the next event.

It is worth noting that the analysis tool 140 can combine the above solutions. For example, if the file 100 was found to be malicious, in one implementation it is possible to stop the execution of the process created when the file 100 is opened. In another embodiment, the execution of the process created when the file 100 was opened, that is, to wait for the next event to further analyze the behavior process threads and log creation 150. In one embodiment, the file 100 is recognized as malicious, but they change the processor context and wait for the next event. Such a sequence of actions is needed to more fully disclose the functionality of file 100. For example, file 100 was found to be malicious after another file containing malicious code was created in the analysis process. However, in some cases (for example, a thread is trying to download something from a maliciously crafted web resource), it makes sense to continue intercepting events and filling log 150 to analyze the further behavior of the process threads created when opening file 100. In another embodiment, even if the file 100 was not recognized as malicious (for example, a window was opened during execution that was waiting for user input), they decide to stop the execution of the process created when the file 100 was opened.

The analysis means 140 passes the decisions to the interceptor 130. The interceptor 130 performs the actions corresponding to the decisions made. If the analysis tool 140 makes a decision to wait for the next event, the execution of the thread that has been suspended by the interception tool 130 resumes.

In one embodiment, the analysis tool 140 initiates a reboot of the virtual machine 120. For example, if a new file was created during the analysis of the file 100, the path to which was added to the startup of the operating system of the virtual machine 120, the analysis tool 140 initiates a reboot to verify the functionality of the created file for malware.

In the general case, after the analysis of the file 100 in the virtual machine 120 is completed, the interception tool 130 transfers the log 150 to the security tool 110. The analysis of the file 100 can be completed both naturally (the threads of the process created when opening the file 100 completed the execution themselves), and by decision analysis tools 140 (analysis tool 140 made a decision to stop the process created when opening the file 100).

Thus, the said system makes it possible to detect the harmfulness of the file 100 based on the decisions from the analysis tool 140, namely, based on whether a decision was made to recognize the file 100 as malicious.

FIG. 3 shows an example implementation of the proposed method for generating a log for anti-virus scanning of a file.

In the general case of generating a log for anti-virus scanning of a file, security tool 110 transmits file 100 to virtual machine 120.

In the General case, the analysis of the file 100 is carried out after it is opened in the operating system of the virtual machine 120. By opening the file 100 is meant one of:

- file execution, if the file is executable;

- opening the file by the application if the file is not executable.

At the initial step 310, an interception 130 is detected during the execution of the process thread created when the said file was opened, the occurrence of an event that is associated with a change in at least one memory page. In the general case, the event associated with a change in the memory page is a call to an API function by a thread. Said event and processor context are stored by interceptor 130 to log 150.

At 320, at least one modified memory page is determined by analysis tool 140 by analyzing data stored in log 150. In one embodiment, identifiers of modified pages are identified when defining modified memory pages. The identifiers of the changed pages, the analysis tool 140 passes to the interception tool 130.

At 330, the control transfer of at least one modified memory page is detected by interception 130, during execution of the process flow created when the file was opened. Transferring control to a memory page generally means that the thread executes the code at the virtual address that is contained on this memory page. In one embodiment, control transfer is detected if the thread executing the code from the modified page is launched from the same process as the thread that changed the memory page. In another embodiment, the control transfer is detected if the thread executing the code from the modified page is launched from a process other than the process whose thread changed the memory page, and.

At step 340 using the analysis tool 140 form a journal 150, which stores:

- events that occur during execution of a process thread created when the mentioned file is opened in the modified memory page;

- the context of the processor that is read when the event is stored in the event log, on which the thread of the process created when the mentioned file was opened is executed.

In one embodiment, at step 350, after generating log 150, at step 340, it is analyzed using analysis tool 140 to determine the harmfulness of the file opened in the virtual machine.

FIG. 4 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. 4. 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, 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 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. One skilled in the art will recognize that there may be other embodiments of the present invention consistent with the spirit and scope of the present invention.

Claims (15)

1. A method for deciding whether to recognize a file opened in a virtual machine as an environment for the safe execution of files, the method comprises the steps of: a) during the execution of the thread of the process created when the mentioned file is opened, the occurrence of an event that is associated with a change in at least one page of virtual memory is detected; b) identify during execution of the process thread created when opening the file, the transfer of control to at least one modified page of virtual memory; c) form a journal in which they save: - events that occur during execution of the process thread created when the mentioned file is opened in the modified memory page, and - the context of the processor that is read when the event is stored in the event log, on which the thread of the process created when the mentioned file was opened is executed; d) compare the events stored in the generated log and the processor context with at least one template; e) make a decision to recognize the file as malicious based on the results of the comparison. 2. The method according to claim 1, in which the event associated with a change in the memory page is a call to an API function during execution of a process thread. 3. The method according to p. 1, in which when determining the changed memory page identifies the identifier of the modified page. 4. The method according to claim 1, wherein the control transfer to the changed memory page is detected if the thread executing the code from the modified page is launched from the same process as the thread that changed the memory page. 5. The method according to claim 1, wherein the control transfer to the changed memory page is detected if the thread executing the code from the modified page is launched from a process other than the process whose thread changed the memory page. 6. The method according to claim 1, in which the template contains at least one rule. 7. The method of claim 6, wherein the rule comprises at least one event. 8. The method of claim 6, wherein the rule comprises at least one processor context.

Images