RU101232U1 - SYSTEM FOR AUTOMATIC CREATION OF MEANS FOR COUNTERING A SPECIFIC TYPE OF MALICIOUS APPLICATIONS - Google Patents

Abstract

 1. The malware component removal system using the selected treatment scenario, which contains:! support tool designed to receive and analyze the event log from the user's computer and create a sequence of treatment instructions for the user's computer, associated with the tool for creating universal treatment algorithms, a tool for storing instructions, a tool for storing script templates, a verification tool, and a tool for executing a treatment script; said means of creating universal treatment algorithms for analyzing an event log and a sequence of instructions received from said support means and creating a treatment script for a user's computer, wherein means of creating universal treatment algorithms is associated with a verification tool, a means for storing script templates and a tool for storing instructions; said means for storing instructions is intended for generating treatment scenarios, as well as for storing a set of specific instructions needed to describe the scripting language; said means for storing script templates is intended for storing universal templates on the basis of which treatment scenarios are created; said means of verification is intended to check the treatment scenario for errors; said means for executing a treatment script is intended to execute a treatment script for removing malware components on a user's computer. ! 2. The system of claim 1, wherein the support tool is also intended�

Description

Technical field

The utility model relates to systems for protection against malicious software and, in particular, to identify components of malicious software. It is based on the automatic collection of statistics and the treatment of infected computer systems.

State of the art

Currently, the spread of malware (hereinafter referred to as software) is increasing, and as a result, the harm that this software causes to computer systems is increasing. Existing systems for protecting personal computers, as well as computers in the corporate network, are based on the detection of already known threats. However, new threats appear more often, and therefore there is a need for their methods of recognition. Due to the growth of communication networks such as the Internet, the volume of data exchange, including the use of mail messages, is constantly increasing. Computer infections can occur with the help of various programs, such as computer viruses or trojans.

Events related to email attacks have significant consequences for both Internet Service Providers (ISPs) and many other companies, which proves the need for improved malware detection strategies.

On the one hand, systems that use signatures have long been used to detect malware. When code patterns that were obtained from known malware and suspected objects are scanned for the presence of patterns in the code. One of the drawbacks of signature-based detection systems is that only known malware can be detected in this way. All malicious programs that were not previously identified as malicious, as well as malicious programs created after updating the signature databases, will not be recognized by this system.

Anti-virus companies continue to update malware signature databases, in addition to creating software databases for scanned or reliable programs (or their executable files), the so-called whitelists, which are becoming more and more popular due to the constant growth in the number of malware . Such lists can be compiled on the basis of many factors: the availability of an electronic digital signature or other data of the manufacturer, data on the source (where the program was received from), data on the program's relationships (parent-child relationship), data on the program version (for example, the program can be considered verified based on the fact that the previous version was also in the list of checked programs), data on environment variables (operating system, startup parameters), etc.

To detect malware, information integrity verification systems are used, which usually create long lists of modified files after operating system updates, when many software updates are installed. The main disadvantage of integrity systems is that the system responds to all changes in the program, although these changes may not be harmful. It is also difficult for the user to decide whether this or that change is an attack on a computer system.

Detection systems using a checksum to search for malware generate a cyclic redundancy code (CRC) value for each program file. Modifications to the program file will be detected if the CRC value changes. Checksum monitoring systems along with the use of integrity systems improve the stability of the overall system. However, checksum monitoring systems have the same drawbacks as integrity verification systems, associated with a large number of false alarms at the slightest change in data.

In case of malware infection, private personal solutions are provided for each computer. Such a personal solution is built on the server of the anti-virus company on the basis of service information about the infected system transmitted by the user's computer to the server. The presented solution is individual and designed to solve a specific problem that arose on the user's computer. Such creation of a solution based on previously known patterns is disclosed in US 7346928, which describes a system consisting of a server that receives requests from multiple clients to scan files for viruses. There are also systems that first create a script for examining an infected computer, and based on the research, a treatment script is created. US Pat. No. 7,093,239 describes a computer analysis system designed to detect malicious code. The system creates and sequentially analyzes the behavior pattern for each program installed on the computer. A behavior pattern is created using a virtual machine. US 7631357 describes a system for detecting and / or removing rootkits. For detection, a “snapshot” of the user's computer system is created using the utility installed on the user's computer. However, despite the fact that a solution is created for a specific problem and takes into account all the features of the problem situation, there are also disadvantages. Such micro-solutions can be used by the user repeatedly, because the user does not always think that this solution is individual and not suitable for solving other problems, albeit rather similar. Users can transfer these solutions to other users who have a similar, but not absolutely identical, problem. When writing individual solutions, the role of the expert of the technical support service is used and, accordingly, there is the likelihood of an expert making a mistake. Writing such decisions takes a long time, because they are written individually for each computer.

An analysis of the prior art and the possibilities that appear when combining them in one system allows you to get a new result, namely: automatically create means of counteracting a certain type of malware.

Utility Model Disclosure

This useful model is designed to automatically create a means of counteracting a certain type of malware.

The technical result is the removal of malicious software components using the selected treatment scenario.

According to one object of the claimed utility model, a malware removal system is provided using a selected treatment scenario that contains:

support tool designed to receive and analyze the event log from the user's computer and create a sequence of treatment instructions for the user's computer, associated with the tool for creating universal treatment algorithms, a tool for storing instructions, a tool for storing script templates, a verification tool, and a tool for executing a treatment script;

said means of creating universal treatment algorithms for analyzing an event log and a sequence of instructions received from said support means and creating a treatment script for a user's computer, wherein means of creating universal treatment algorithms is associated with a verification tool, a means for storing script templates and a tool for storing instructions;

said means for storing instructions is intended for generating treatment scenarios, as well as for storing a set of specific instructions needed to describe the scripting language;

said means for storing script templates is intended for storing universal templates on the basis of which treatment scenarios are created;

said means of verification is intended to check the treatment scenario for errors;

said means for executing a treatment script is intended to execute a treatment script for removing malware components on a user's computer.

In a particular embodiment, the support tool is also intended to receive an event log from the user's computer, in which a list of events is recorded on the user's computer.

In a particular embodiment, the tool for creating universal treatment algorithms is also intended to create a treatment scenario in the form of a sequence of instructions based on an analysis of the event log and the subsequent selection of a scenario template.

In a particular embodiment, the treatment script execution facility is also provided for storing the treatment script in an executable file.

In a particular embodiment, the tool for creating universal treatment algorithms is also intended to save the created treatment scenarios.

In a particular embodiment, the tool for creating universal treatment algorithms is also intended to transmit the treatment scenario to the verification tool for checking the treatment scenario for errors.

In a particular embodiment, the verification tool is also designed to prohibit the execution of the script if errors are found that pose a threat to the user's computer, and transmitting to the support tool a treatment script and a report on the investigated errors.

In a particular embodiment, the verification tool is also intended to permit the execution of the script if no errors are found that pose a threat to the user's computer and the treatment script is transmitted to the support tool.

In a particular embodiment, the verification tool is also intended to parse the treatment scenario and check for dangerous actions for the computer system.

In a particular embodiment, the tool for creating universal treatment algorithms is also intended to create a treatment script in text format.

Brief Description of the Drawings

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

Figure 1 shows an exemplary embodiment of a malware component removal system using a selected treatment scenario.

Figure 2 shows an exemplary embodiment of a block diagram of a malware component removal system using a selected treatment scenario.

Figure 3 shows an exemplary embodiment of a block diagram of a data transmission between system tools.

Figure 4 shows an exemplary embodiment of communication in a malware component removal system using a selected treatment scenario for implementing a corporate network.

5 shows an exemplary embodiment of a flowchart of a verification tool.

Description of Embodiments of a Utility Model

Next, exemplary embodiments of the present utility model will be described with reference to the accompanying drawings. The objects and features of this utility model will become apparent by reference to exemplary embodiments. The present utility model is not limited to the exemplary implementation options disclosed below, it can be embodied in various forms. The entity defined in the description is nothing more than the specific details provided to assist the person skilled in the art in an exhaustive understanding of the utility model, and the present utility model is determined only in the scope of the attached formula.

The present utility model is used in general-purpose computers, for example, ordinary computers or servers. Such computers contain a processor, system memory, and a system bus that connects various system components, including system memory, to the processor. A system bus can be one of several types of bus structure, including a memory bus or memory controller, a peripheral bus, and a local bus using any bus architecture. System memory includes read-only memory (ROM) and random access memory (RAM).

The basic input / output system (BIOS) contains the basic programs that help transfer information between the elements of a computer system, and is stored in ROM. The computer may further comprise a hard disk drive for reading or writing to a hard disk, a magnetic disk drive for reading from or writing to a removable magnetic disk, and an optical disk drive for reading from or writing to a removable optical disk such as a CD-ROM DVD-ROM or other optical media.

The hard disk drive, the magnetic disk drive, and the optical disk drive are also connected to the system bus through the hard disk drive interface, the magnetic disk drive interface, and the optical disk drive interface, respectively. Storage devices and related computer-readable media provide non-volatile storage of computer-readable instructions, data structures, program modules and other computer data.

The computer may also contain magnetic cassettes, flash memory cards, digital video discs, Bernoulli cartridges, random access memory (RAM), read-only memory (ROM) and other types of memory.

A number of software modules may be stored on a hard disk, magnetic disk, optical disk, ROM or RAM, including an operating system (for example, Windows ™ 2000). The computer also includes a file system associated with / included in the operating system, such as the Windows NT ™ File System (NTFS), one or more application programs, other program modules and program data. The user can enter commands and information into the computer using input / output devices such as a keyboard and pointing device (mouse).

Other input devices may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other I / O devices are connected to the processor via the serial port interface, which is connected to the system bus. It should be noted that these devices can connect to other interfaces, such as a parallel port or universal serial port (USB). A monitor or other type of display device also connects to the system bus via an interface, such as a video adapter. In addition, the computer may include other peripheral output devices, such as speakers and printers.

A computer using the claimed systems operates in a network environment using logical connections with one or more remote computers. The remote computer (or computers) can be other computers, servers, routers, network PCs, a peer device, or another common network node. This computer can be connected to a local area network (LAN) or to a wide area network (WAN), to a network in offices, the Internet or an Intranet.

When the computer is used in a LAN network environment, the computer connects to the local network through a network interface or adapter. When used in a WAN network environment, a computer typically includes a modem or other means to establish communications over a wide area network such as the Internet. The modem, which can be internal or external, is connected to the system bus via the serial port interface.

This useful model describes a system for automatically creating means to counter a certain type of malware.

One of the directions of the utility model is a system for removing components of malicious software using the selected treatment scenario. In accordance with an embodiment, treatment scenarios are automatically generated based on information received from a user's computer infected with a malicious program.

To automatically create treatment scenarios, a malware component removal system is used using the selected treatment scenario 100, shown in FIG. The presented system 100 includes a user computer 110, which transmits to the support tool 120 an event log designed to record a list of events on the user's computer. Then, the support tool 120, based on the received event log and using the tool for storing the treatment scenario 135, creates a sequence of instructions for treating the user's computer 110. Methods for generating a sequence of instructions, including in the form of scripts, are discussed in patents and applications like EP0605166 , JP 101493 01, JP2000222194, JP2001175481, KR20010076775. An instruction storage means for generating a treatment scenario 135 contains a set of special instructions needed to describe a scripting language. Further, the support tool transmits to the tool for creating universal treatment algorithms 130 a sequence of instructions and an event log received from the computer 110 of the user. The universality of the tool 130 lies in the fact that it makes up solutions for different types of individual problems automatically. The tool for creating universal treatment algorithms 130, on the basis of the obtained data, selects a treatment scenario template from the scenarios in the scenario template storage tool 145 and creates a treatment scenario. Analysis of the event log can be implemented in the form of one of the methods described in patents and applications such as US5121475, JP3034038, JP7182210, US2003040889. The script template storage tool 145 contains patterns for creating treatment scripts for a computer, which are patterns for solving common problems. Templates for solving common problems can be stored in a database such as MySQL, DB2, PostgreSQL, SQLite. The created script is sent for verification to the verification tool 150. The verification tool 150 checks the treatment script for syntax errors (instructions) and logical errors (sequence of instructions) so that the execution of the treatment script on the user's computer 110 does not harm him. Verification tool 150 also checks to see if important files were deleted in the treatment script. For example, if a treatment script deletes the Explorer.exe file, then the verification tool is very likely to find the treatment script to be erroneous. Verification methods (checks) are described in such applications and patents as US2004044992, US2003028830, JP61023250, JP4151743, JP7283847. If the verification is successful, then the verification tool 150 returns the treatment script to the universal treatment algorithm creation tool 130. The support tool 120 may affect the operation of the script template storage tool 145 and the verification tool 150, for example, correct or supplement. If the treatment scenario is corrected by means 120, then it sends the corrected treatment scenario to verification tool 150. If the treatment scenario contains actions that can harm the computer system, then verification tool 150 adds this case to the verification conditions and returns the treatment scenario and error report to the universal creation tool treatment algorithms 130. The tool for creating universal treatment algorithms 130 corrects the treatment scenario based on a report from the verification tool 130. In a particular embodiment, Menno at impossibility of automatic correction, treatment of the script can be corrected by the expert 125. In case of a successful script treatment means creating universal treatment algorithms 130 creates a unique solution for your computer in the form of a single executable file. Then the executable file is transferred to the support tool, and through it to the treatment script execution tool on the user's computer. The execution of the scripts is disclosed in such patents as US5715386, JP9167085, JP9305381, US5754760, US6275868, US6332217. The advantage of saving the treatment script to an executable file is that the user will not be able to view or modify the treatment script. To protect against the user, it is possible, after executing the treatment script itself, to enable “file self-destruction” or “blocking”. Thus, if the self-destruction of a file is included in the script, the means of executing the treatment script will work on the user's computer only once. If the lock is enabled, then the treatment script execution tool will be executed only on the computer for which it was created. To implement the blocking of the tool for executing the treatment script, the computer 110 is assigned a unique identifier, which is generated on the basis of data about the computer: the serial number of its disk, version of the operating system, etc.

The presented system is a solution for treating a computer from typical problems. Figure 2 illustrates an exemplary algorithm of the present system. It depicts the creation and use of a treatment scenario that is one-off. If there is any problem on the user's computer related to malware, it is not enough to perform only virus removal, as there are traces of the virus that the antivirus application is not able to remove. Therefore, the user sends the event logs of the infected computer system to the support service at step 210. In this situation, the support tool should create a sequence of instructions based on the event log at step 215, which is then passed to the tool for creating universal treatment algorithms 130 in step 220. The data is used to generate a treatment scenario instructions from the storage facility for generating treatment scenarios 135. The treatment scenario is encrypted at step 225. Based on the script using the script template from To save script templates 145, the universal treatment algorithms creation tool 130 creates an executable file to solve this characteristic problem in step 230. The executable file is always built with different anti-virus signatures (that is, it does not have static signatures), which allows you to hide malware from attention such an assembly of treatment scenarios, and they cannot block the launch of the presented executable file. At step 235, the tool for creating universal treatment algorithms 130 sends the file to the user. At step 240, the user runs the file on the infected computer. Moreover, the virus cannot determine that this application is intended to treat a computer system, because it is not installed in the folder of the anti-virus application, does not contain any identifiers of the anti-virus application (such as the name of the anti-virus application in the file name, or information about the creator of the file), and does not save child files to disk. After the study file is completed, the event and file logs are collected, which are then sent to the support service in step 245 without user intervention. The support service receives files from the user in step 250 and saves them for further investigation. After that, execution may continue from step 210.

The malware component removal system using the selected treatment scenario depicted in FIG. 3 is also a portable diagnostic tool operating without user intervention. First of all, a user-generated event log is created in step 310, which is then sent to the support service in step 320. Based on the log, a research script is written in step 330, which analyzes the state of the computer system for which treatment is necessary. The study script is sent to the user's computer in step 340. At step 350, data from the execution of the study script is output. Based on these data, a conclusion is made about the state of the computer at step 360, which is then provided to the user. The research scenario is typical and may practically not change (it changes only in case of changes in operating systems, the emergence of new architectural solutions, etc.). Similar research scenarios can also be created for automatic quarantine and collection of potentially harmful program templates, cleaning the computer system of traces of malicious program behavior.

The presented embodiment of the malware component removal system using the selected treatment scenario can be used to create a solution for administering corporate networks, as shown in Fig. 4. The anti-virus program installed on the computer of the administration tool 420 of the corporate network 410 includes a component that allows you to organize and control the protection in the corporate network 410. For a centralized check of the network computers, the administration tool 420 sends a request to the network agents 425, pre-installed on the users computers, executable file 430, containing the research scenario, in the form of a task. In turn, the network agent runs this file and returns the 440 data to the administration tool (for example, by e-mail). This implementation option can be used for mass inspection of computers in a corporate network 410. The advantages of this application are the work of the research script without preliminary installation, the presence of a single executable file, etc.

The presented system creates a tool for the entire treatment process on a user computer system. A single executable file is launched on the user's computer. In this case, the executable file can be located anywhere, i.e. either directly on the user's computer, or run from a web page or from a mail message.

In order to protect the treatment script from running on other computers, it is possible to establish the connection between the executable file and the specific computer for which the executable file is intended. This treatment scenario, after binding to a specific computer, will not start on other computers and will not be able to harm other computer systems. Also, the presented executable file with the treatment script can self-destruct, or prevent launching two or more times.

The system also contains a verification tool designed to check the treatment scenario for syntactic correctness and for logical errors dangerous for the computer system. A flowchart of the verification process is shown in FIG. After the support tool creates a treatment script, it sends it for verification to the verification tool at step 510. At step 520, the verification tool passes the script through a set of syntax checks. If no errors were found in step 530, the verification tool checks the script step by step for the danger to the system in step 540. If dangerous operations are detected in step 550, the verification tool encrypts the investigation file in step 560. Then, in step 570, the verification tool resolves script execution. If dangerous operations or errors are detected in step 530 or in step 550, the verification tool prohibits the execution of the treatment scenario in step 535. Then, in step 545, the verification tool saves the conditions under which an error occurs. At step 555, the verification tool sends the script to the universal treatment algorithm generator with a study report for errors. At step 580, the verification tool terminates.

In conclusion, it should be noted that the information given in the description are only examples that do not limit the scope of this utility model defined by the formula. The person skilled in the art will understand that there may be other options for implementing this utility model, consistent with the nature and scope of this utility model.

Claims (10)

1. The malware component removal system using the selected treatment scenario, which contains: support tool designed to receive and analyze the event log from the user's computer and create a sequence of treatment instructions for the user's computer, associated with the tool for creating universal treatment algorithms, a tool for storing instructions, a tool for storing script templates, a verification tool, and a tool for executing a treatment script; said means of creating universal treatment algorithms for analyzing an event log and a sequence of instructions received from said support means and creating a treatment script for a user's computer, wherein means of creating universal treatment algorithms is associated with a verification tool, a means for storing script templates and a tool for storing instructions; said means for storing instructions is intended for generating treatment scenarios, as well as for storing a set of specific instructions needed to describe the scripting language; said means for storing script templates is intended for storing universal templates on the basis of which treatment scenarios are created; said means of verification is intended to check the treatment scenario for errors; said means for executing a treatment script is intended to execute a treatment script for removing malware components on a user's computer. 2. The system according to claim 1, in which the support tool is also designed to receive an event log from the user's computer, in which a list of events is recorded on the user's computer. 3. The system according to claim 1, in which the tool for creating universal treatment algorithms is also intended to create a treatment scenario in the form of a sequence of instructions based on an analysis of the event log and the subsequent selection of a scenario template. 4. The system according to claim 1, in which the means of executing the treatment scenario is also intended to save the treatment scenario in an executable file. 5. The system according to claim 1, in which the tool for creating universal treatment algorithms is also designed to save the created treatment scenarios. 6. The system according to claim 1, in which the tool for creating universal treatment algorithms is also intended to transmit the treatment scenario to the verification tool for checking the treatment scenario for errors. 7. The system according to claim 6, in which the verification tool is also designed to prohibit the execution of the script if errors are found that pose a threat to the user's computer, and the transmission to the support tool of the treatment script and report on the investigated errors. 8. The system according to claim 6, in which the verification tool is also designed to permit the execution of the script, if no errors are found that pose a threat to the user's computer, and the transfer of the treatment script to the support tool. 9. The system according to claim 6, in which the verification tool is also intended to syntactically verify the treatment scenario and check for dangerous actions for the computer system. 10. The system according to claim 1, in which the tool for creating universal treatment algorithms is also intended to create a treatment scenario in text format.