RU2757807C1 - System and method for detecting malicious code in the executed file - Google Patents

Abstract

FIELD: information security.

SUBSTANCE: technical result is achieved by confirming the presence of malicious code in the executed file similar in the metadata to a trusted file.

EFFECT: ensured protection of information security.

8 cl, 3 dwg

Description

Technology area

The invention relates to the field of information security, and more specifically to systems and methods for checking files for malicious code.

State of the art

The number of new applications created by users and companies continues to grow. Improved programming environments and out-of-the-box program designers greatly simplify and speed up the process of creating or modifying applications. Versions and alternate assemblies of the same application rarely result in a completely new executable file. Often, the difference in functionality of the mentioned executable files during a detailed analysis may turn out to be insignificant.

Existing compilation methods, due to their complexity, allow you to create applications of the same functionality in the form of various executable files. On the other hand, it is possible to create two identical executable files that will have a different set of functions.

The constantly growing number of applications and their constant change, for example, as a result of installing updates, does not allow the user to have up-to-date information about the current correctly working and most secure version of the application assembly. At the same time, software developers do not always have the ability to keep track of the release of different versions of assemblies of the applications they create. This situation can be exploited by an attacker.

Attackers can take advantage of this complexity and deliberately create a malicious executable file that looks like the executable file of a known application, but has malicious functionality. On the other hand, it is possible to create several different malicious executable files that will have the same or similar malicious functionality. To identify functional differences, the analysis of information about the files of the source code of the executable files is used.

Currently, there are solutions for detailed comparison of source code files. For example, publication US9569199B2 describes a system that compares the text of source code files. The comparison results are used to quickly create an update or new version of an application assembly.

Although the method described above successfully copes with the task of detailed comparison of source code files, it does not imply an anti-virus check of the functionality of different versions of the application assembly. The present invention makes it possible to effectively solve this problem.

Disclosure of invention

The invention relates to the field of information security, and more specifically to systems and methods for checking files for malicious code. The invention is intended to check for the presence of malicious code in an executable file. The technical result of the present invention is to provide information security protection. The specified technical result is achieved by performing a check for the presence of malicious code in the executable file, which is similar in metadata to the trusted file.

In one embodiment, a method is provided for detecting malicious code in an executable file, by which: determining metadata containing information about the version of an assembly of the executable file; select from the database of trusted files at least one executable file, the metadata of which is similar to certain metadata; determining a functional block in the executable file that is absent in at least one selected executable file; detect the presence of malicious code in an executable file using assembly validation rules and based on a specific functional block.

In another embodiment of the method, under the metadata containing information about the version of the assembly of the executable file, there are at least the following metadata: the version number of the assembly; File name; file size; unique lines extracted from the file; file structure; and the contents of the import, export and resource sections.

In another embodiment of the method, executable files, lists of files and source code modules, individual files and source code modules, symbol files of various versions of assemblies of executable files and applications that correspond to at least one of the following conditions are stored in the database of trusted files: which were previously checked for the presence of malicious code, the origin of which has been confirmed by the creator of the software.

In another embodiment of the method, the functional block represents a set of program instructions that ensure the execution of a given task.

In yet another embodiment of the method, the definition of the functional block in the executable file is performed based on at least one source code file that is absent in the selected file.

In another embodiment of the method, a functional block in the executable file is determined based on at least one source code module that is absent in the selected file.

In yet another embodiment of the method, the executable file and the file selected from the database of trusted files belong to assembly versions of the same application.

In another embodiment of the method, an assembly check rule is understood as a set of conditions under which the probability that the executable file contains malicious code is determined.

Brief Description of Drawings

FIG. 1 illustrates the structure of a system for detecting malicious code in an executable file.

FIG. 2 illustrates the algorithm of the system for detecting malicious code in an executable file.

FIG. 3 is an example of a general purpose computer system, personal computer or server.

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

Description of embodiments of the invention

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

An executable file is a file containing a program or a part of it, written in any of the programming languages, intended to be launched by an operating system. ¹ ( ¹ Felix Voroisky. Informatics. Encyclopedic Dictionary-Reference. - Litres, 2017-01-12. - 769 pp. - ISBN 9785457966338.)

An application assembly is an executable file, set of files, or logical structure that contains program code, metadata, and resources necessary for the correct compilation or execution of an application. B. NET Core and .NET Framework, an assembly can be created from one or more source code files. B. NET Framework assemblies can contain one or more modules. In large projects, multiple developers can work with separate files or modules of source code that together form a single assembly. ² ( ² Official site of Microsoft Corporation. URL: https://docs.microsoft.com/ru-ru/dotnet/standard/assembly/#assembly-manifest (date of access 07/30/2020).)

A functional block is a hardware and / or software object that performs a specific task. ³ ( ³ GOST Ρ 53195.4-2010: Functional safety of systems related to the safety of buildings and structures. Part 4. Software requirements.) The source code of the program during creation can be divided into functional blocks. A separate file or module of the application source code can be a function block. The collection of files and modules of the source code, which is responsible for the execution of a particular action, can also be a functional block.

Symbols file - a file designed to store debug information about the program, including information about symbols, which consists of a list of all symbols in the program unit with addresses, file name and the line in which the symbol was declared, information about the optimization of pointers to activation records, name and information about the type of local variables and the data structure. Among the symbol files, files with the extensions COFF, DBG, SYM, PDB are known. ⁴ ( ⁴ Official website of Microsoft Corporation. URL: https://devblogs.microsoft.com/devops/understanding-symbol-files-and-visual-studios-symbol-settings/ (date of access 07/30/2020).)

The list of files and modules of the source code of the application assembly contains a list of data about all files and modules of the source code of the assembly, without connection and the presence of which the compilation of the assembly executable file is impossible, and their hash sums. The list can be obtained by processing symbol files or other data source that contains information about the files and modules of the source code of the assembly version of the application.

In the first case, an attacker can covertly inject malicious code into an existing trusted and trusted application, the source files of which are in the public domain or to which unauthorized access has been obtained. In the second case, an attacker can create multiple copies of one malicious application, which will be identified by the antivirus program as different applications, and each will be scanned separately for the presence of malicious code, although, in fact, it is one and the same application.

In order to identify unsafe applications from the listed cases, they use a malicious code detection system in an unknown version of the application assembly. 1 illustrates a system for detecting malicious code in an executable file, which includes a trusted file database 110, a detector 120, a parser 130, a validator 140, a rule database 150.

Database of trusted files 110 - a repository of executable files, their corresponding lists of files and source code modules, individual files and source code modules, symbol files of different versions of application assemblies that meet at least one of the following conditions: which were previously checked for the presence of malicious code, the origin of which can be clearly confirmed by the creator of the software. The database of trusted files 110 is augmented from open source repositories of software developers such as sourceforge, githup, and others; private repositories of software developers, such as Microsoft, Adobe and others. A private repository is accessed, for example, through a direct request to check for malicious code for a specific application or executable file. In addition, the data can come from the anti-virus server.

The detector 120 is designed to determine metadata containing information about the assembly version of the executable file, select from the database of trusted files 110 an executable file whose metadata is similar to the specified metadata, transfer information about the executable file and the selected file to the analysis tool 130.

The metadata containing information about the version of the assembly of the executable file, which is used to search for similarity, can be at least the following metadata: assembly version number, file name, file size, unique strings extracted from the file, file structure, contents of import and export sections, resources.

Fetching from the database of trusted files 110 is performed both by one type of metadata, for example, by the file name, and by a set of types, for example, by the assembly version number, the file size and the contents of the import section. Both clear and fuzzy similarity testing algorithms are used. A percentage is created for the entire list of metadata. The similarity of the analyzed files for a given list of metadata means 100% similarity. The difference in one type of metadata reduces the similarity by the corresponding percentage value. The sampling results in at least one secure file from the trusted file database 110 and all associated data.

The detector 120 then transmits information about the executable file and the selected file to the analyzer 130.

The analysis tool 130 is designed to determine a functional block in the executable file that is not present in at least one selected file, and transmit data about the determined functional block to the checking tool 140.

The definition of a functional block is carried out by performing the following list of actions. First, the list of files and modules of the source code in the executable file is revealed. Second, the lists of files and modules of the source code of the executable file and the selected file from the database of trusted files 110 are compared. Third, the results of the comparison identify files and modules of the source code that are missing or different, and combine them into a separate functional block.

When you create different versions of application assemblies, software development environments and programming languages provide the ability to create symbol files for each source file and unit. Based on the symbol files, a list of files and modules of the source code is calculated and stored, for example, in the following form:

"0 c: \ program files (x86) \ windows kits \ 10 \ include \ 10.0.17763.0 \ ucrt \ sys \ stat.h (MD5: 8DCC3C7F28EF6CADCEA54C4F1881C8D3)"

In one case, said symbol files may be part of a compiled file. Alternatively, symbol files may be among the source files, for example, as a PDB (Program DataBase) file. For example, for interpreted programming languages, a list of files and source code modules can be obtained by directly calculating the hash sums of all files in an application or script.

After determining the functional block, the analyzer 130 transmits the data about the determined functional block to the verifier 140.

The validator 140 is designed to detect the presence of malicious code in an executable file using assembly validation rules and based on a specific functional block.

The rules database 150 is for storing assembly validation rules. As a database of rules 150, various types of databases can be used, namely: hierarchical (IMS, TDMS, System 2000), network (Cerebrum, Cronospro, DBVist), relational (DB2, Informix, Microsoft SQL Server), object-oriented (Jasmine, Versant, POET), object-relational (Oracle Database, PostgreSQL, FirstSQL / J), functional, etc. The number of rules is not limited by examples. Rules can be created using machine learning algorithms and automated processing of large amounts of data, and contain other conditions or combinations of conditions, verdicts.

Checking for malicious code of an executable file includes checking all files and modules of the source code, taking into account the data on the similarity of the executable file and the selected file. Files and modules of the source code of the executable file, which are identical to the files and modules of the source code of the selected file, can be partially or completely excluded from scanning. Files and source code modules that are missing or different, which have been combined into a functional block, are subject to detailed analysis for the presence of malicious code using assembly check rules.

An assembly validation rule is a set of conditions that determine the likelihood that an executable file contains malicious code.

One of the examples of the implementation of assembly verification rules can be the fulfillment of the following conditions: the executable file and the selected file are 90 percent similar when checking the metadata similarity, a certain functional block cannot be found, the verdict is the probability of the presence of malicious code is more than 80 percent. The presented set of conditions clearly indicates that the executable file does not contain symbol files, unlike the selected file. The use of symbol files is an essential parameter in the development process and cannot be simply overridden. This indicates that an attacker gained access to the build process of the selected file and created an executable file containing malicious code.

Another example of the implementation of assembly verification rules can be the fulfillment of the following set of conditions: the executable file and the selected file are similar in metadata by 90 percent, a certain functional block is from 1 to 10 percent of the total number of functional blocks, in one of the files and modules of the source code from a certain functional block, the presence of malicious code was detected, the verdict is the probability of the presence of malicious code 80 percent.

The third example of the implementation of assembly verification rules can be the fulfillment of the following set of conditions: the executable file and the first selected file are similar in metadata by 50 percent, a certain functional block is 5 percent of the total number of functional blocks, the executable file and the second selected application file are similar in metadata by 50 percent, a certain functional block is 5 percent of the total number of functional blocks, the verdict is the probability that the executable file contains malicious code, 60 percent. This set of conditions indicates that a massive creation of similar applications has been detected.

In the most general case, the metadata of executable file 1, for example, can be as follows: assembly version number 1, file name 1, file size 1, unique lines 10, file structure 1, import section contains 18 imported files, export section contains 1 exported file, the resource section contains 3 files. Suppose that file 2 was found and selected using the listed metadata in the database of trusted files 110, the metadata of which is as follows: assembly version number 1, file name 1, size 2, unique lines 10, file structure 1, unique lines 10, file structure 1 , the import section contains 19 imported files, the export section contains 1 exported file, the resources section contains 3 files. In addition, for file 2, a corresponding list of files and modules of the source code was found, consisting of 30 positions, according to which 25 functional blocks were built. Detection tool 120 detects the following differences found: size 2 is 5 percent larger than size 1, 1 imported file in the import section of the selected file does not appear in the metadata of the executable file. Calculating the degree of similarity showed that the executable file is more than 90 percent similar to the selected file. Based on this data, the parser 130 determines the presence of a symbol file and, based on this, determines a list of files and source code modules. The defined list contains 32 positions on the basis of which 26 functional blocks are identified. 25 out of 26 function blocks and 30 out of 32 files and modules of the source code are identical with the function blocks of the selected file. Determine that the selected file does not contain 1 functional block of the executable file. Thus, 26 function blocks are taken as 100 percent, and a specific function block is 4 percent. Based on this data, the validator 140 and the assembly validator rules from the rule database 150 discovers that, according to the second rule example, the executable file contains malicious code with an 80 percent probability. Files and modules of the source code that contain a certain functional block are subjected to more complex and detailed analysis to find out where and how the malicious code is executed.

Build validation rules can also be created to detect unrecorded executable files. For example, a system for detecting malicious code in an executable file can be installed or implemented in a software development environment. In this case, assembly validation rules can be configured to identify all executable files that were not created in the mentioned software development environment, department, individual worker, etc. In addition, assembly validation rules can be configured to detect critical changes in the functional blocks of the executable file of newer assembly versions. For example, a system for detecting malicious code in an executable file can be installed or deployed in code analysis centers as part of a transparency initiative. In this case, assembly verification rules can be configured to identify executable files of different versions, the functional blocks of which are very different from the reference version and may have a dubious effect on the company's reputation when checked by the code analysis center.

FIG. 2 illustrates the algorithm of functioning of the system for detecting malicious code in an executable file. At block 211, the detector 120 determines the metadata containing the assembly version information of the executable file. In step 212, the detector 120 selects from the database of trusted files 110 at least one executable file whose metadata is similar to the specified metadata, and transmits information about the executable file and the selected file to the analyzer 130. In step 213, the analyzer 130 determines the functional a block in the executable file, which is absent in at least one selected file, and transmits data about a specific functional block to the verifier 140. At step 214, the verifier 140, using assembly verification rules and based on a specific functional block, detects the presence of malicious code in the executable file ... In the presence of malicious code, at step 215, the checker 140 sends data about the executable file containing the malicious code to the anti-virus server. In the absence of malicious code at block 216, the system shuts down.

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

The personal computer 20, in turn, contains a hard disk 27 for reading and writing data, a magnetic disk drive 28 for reading and writing to removable magnetic disks 29 and an optical drive 30 for reading and writing to removable optical disks 31, such as CD-ROM, DVD -ROM and other optical media. The hard disk 27, the magnetic disk drive 28, and the optical drive 30 are connected to the system bus 23 through the hard disk interface 32, the magnetic disk interface 33, and the optical drive interface 34, respectively. Drives and corresponding computer storage media are non-volatile storage media for computer instructions, data structures, program 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 are possible that are capable of storing data in a computer readable form (solid state drives, flash memory cards, digital disks, random access memory (RAM), etc.), which 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 has the ability to enter commands and information into the personal computer 20 through input devices (keyboard 40, manipulator " mouse "42). Other input devices may be used (not shown): microphone, joystick, game console, scanner, etc. Such input devices are conventionally connected to the computer system 20 through a 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 a universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface such as a video adapter 48. In addition to the monitor 47, the personal computer may be equipped with other peripheral output devices (not displayed), such as speakers, a printer, etc. ...

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

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, personal computer 20 is connected to local network 50 via a network adapter or network interface 51. When using networks, personal computer 20 may use a modem 54 or other means of providing communication with a wide area network, such as the Internet. Modem 54, which is an internal or external device, is connected to the system bus 23 via a serial port 46. It should be noted that the network connections are only exemplary and are not required to reflect the exact configuration of the network, i. E. in fact, there are other ways of establishing a connection by technical means of communication of one computer with another.

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

Claims (12)

1. A method for detecting malicious code in an executable file, according to which: a) define metadata containing information about the version of the assembly of the executable file; b) select from the database of trusted files at least one executable file, the metadata of which is similar to certain metadata; c) define a functional block in the executable file that is absent in at least one selected executable file; d) detect the presence of malicious code in an executable file using assembly check rules and based on a specific functional block. 2. The method according to claim 1, whereby under the metadata containing information about the version of the assembly of the executable file, there are at least the following metadata: the version number of the assembly; File name; file size; unique lines extracted from the file; file structure; and the contents of the import, export and resource sections. 3. The method according to claim 1, according to which executable files, lists of files and modules of the source code, individual files and modules of the source code, symbol files of various versions of assemblies of executable files and applications that correspond to at least one of the following conditions: in relation to which a check for the presence of malicious code was previously performed, the origin of which has been confirmed by the creator of the software. 4. The method according to claim. 1, in which the functional block represents a set of program instructions that ensure the execution of a given task. 5. The method according to claim 1, wherein the definition of the functional block in the executable file is performed based on at least one source code file that is not present in the selected file. 6. The method according to claim 1, according to which the functional block in the executable file is determined based on at least one source code module that is absent in the selected file. 7. The method according to claim 1, wherein the executable file and the file selected from the database of trusted files belong to assembly versions of the same application. 8. The method according to claim 1, according to which the assembly verification rule is understood as a set of conditions, under which, the probability that the executable file contains malicious code is determined.

Images