Operating system consistency and malware protection

Methods, systems, and computer program products are included for determining the risk that a file includes malware. The risk is determined by sending identifying information of the file from a client to a server. The server matches the identifying information with identifying information stored in a registry, in order to identify the file. Once the file is identified, the server identifies the risk of malware corresponding to the file, and sends the risk information to the client. The client is able to use the risk information to make determinations regarding performing operations with regard to the file.

BACKGROUND

Malware is a term that refers to malicious software. Malware includes software that is designed with malicious intent to cause intentional harm. Examples of malware include viruses, worms, ransomware, spyware, adware, rootkits and so forth. In many cases, malware takes the form of executable code stored in a binary file that is unknowingly executed by a user of a computing device.

Malware causes many issues for users. For example, malware may negatively affect the resources of the computing device, invade users' privacy by stealing information, adversely affect computing devices' stability, and hijack users' computing device for illegitimate purposes. In many instances, users may not even be aware of the presence of the malware.

Programs such as anti-virus software are used to detect and remove malware. Anti-virus software may compare malware signatures to data of programs stored on the computing device. Matches between malware signatures and program data may indicate the presence of malware. The malware signatures can be stored in large databases that include thousands of malware signatures. Often, there are a large number of files that are scanned to detect the malware signatures. Programs can be scanned each time they are executed, resulting in a large number of scans. Detection of malware may therefore involve non-trivial amounts of computing device processor and/or memory resources.

BRIEF SUMMARY

According to an example, a computer-implemented method for identifying malware using a registry includes receiving a first file identification information from a first client of a plurality of clients, wherein the first file identification information corresponds to a first file and includes a received file path, a received version, and a received architecture. The method further includes querying a data store for a second file identification information that matches the first file identification information, wherein the second file identification information includes a stored path, a malware risk value, and a file counter. The method further includes detecting a degree of match by matching between the received file path and the stored file path. The method further includes incrementing the file counter. The method further includes determining a risk score based on the degree of match, the file counter, and the malware risk value. The method further includes returning the risk score to the first client.

According to an example, a non-transitory computer-readable medium for identifying malware using a directory service registry includes computer-readable instructions, the computer-readable instructions executable by a processor to cause the processor to: receive a first identification information from a client, the first identification information corresponding to a first file. The medium further includes instructions to compare the first identification information and a second identification information to determine a match, the second identification information corresponding to a second file. The medium further includes instructions to retrieve a file counter associated with the second file. The medium further includes instructions to retrieve a malware risk value associated with the second file. The medium further includes instructions to, based on the file counter and the malware risk value, determine a risk score associated with the first file. The medium further includes instructions to return the risk score to the client.

According to an example, a registry system for determining malware risk includes a client including a processor in communication with a memory, the client to: detect an operation corresponding to a first file, determine a first information associated with the first file, the first information including a first hash code, a first file path, a first version, and a first architecture. The system further includes a server communicatively coupled to the client, the server having a directory service and a registry, the directory service to: receive the first information from the client; retrieve, from the registry, a file counter corresponding to the first information; retrieve, from the registry, a malware risk value corresponding to the first information; determine a risk value corresponding to the first information based on the file counter, the malware risk value, and a matching between the first file path and a second file path; and notify the client of the risk value, prior to the client installing the first file.

DETAILED DESCRIPTION

FIG. 1illustrates an exemplary system architecture100for malware detection in which examples of the present disclosure can be implemented.

System architecture100includes a client102. Client102may be a user machine, such as a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone or other mobile device, or any machine capable of executing a set of instructions (sequential or otherwise). Further, while one client is illustrated, the term client shall also be taken to include any collection of computing devices that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. System architecture100may include a single client or plurality of clients.

Client102runs an operating system104that manages hardware and software of the respective user machine. In the present embodiment, the client102runs the operating system by booting the operating system104during a boot process. The operating system104may be any standard or proprietary operating system. The operating system is configured to install and execute one or more applications, such as anti-malware application106. The operating system104may install and execute applications with or without active human interaction.

In the present embodiment, the operating system104is structured to run an anti-malware application106. The anti-malware application106is structured to identify malware and take remedial action. In the present example, the operating system104runs the anti-malware application106during a boot process of the operating system. In other examples, the anti-malware application106is executed prior to booting the operating system104, in order to detect malware in the operating system104itself. In other examples, the anti-malware application106is executed after booting the operating system, in order to perform malware analysis on each subsequently executed application.

Anti-malware application106is structured to determine hash codes corresponding to files. Hash codes may be determined by analyzing files using algorithms such SHA or MD5. The anti-malware application106may include a data store that is structured to store hash codes associated with files. The anti-malware application is structured to compare hash codes of files with one or more hash codes stored in the data store to detect matches. A hash code match may identify that the file is approved for the particular operation. For example, if the detected operation is a file execution, a match between the file's hash code and one of the stored hash codes may identify that the file is approved for execution. Inability to locate a match for a file's hash code in the data store may trigger additional actions. Additional actions may include, for example, contacting a server110to receive malware-related information regarding the file.

The client102is communicatively coupled via a connection108to a server110. The connection108may represent any combination or physical and/or wireless connections. Each connection may be part of a network. A network may be a public network (e.g., the Internet), a private network (e.g., a local area network (LAN) or wide area network (WAN)), or a combination thereof. In an example, the network may include the Internet and/or one or more intranets, landline networks, wireless networks, and/or other appropriate types of communication networks. In an example, the network may comprise a wireless telecommunications network (e.g., cellular phone network) adapted to communicate with other communication networks, such as the Internet.

In the present example, the client102is structured to send and receive data associated with the anti-malware application106via the connection108, in order to communicate with the server110. The server110is also structured to communicate with client102via the connection108.

The server110may represent one or more server machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. Examples of server machines include enterprise servers, personal computers (PCs), and any machines capable of executing a set of instructions (sequential or otherwise).

In the present example, the server110is structured with a directory service112, a directory service registry114and an anti-malware scanner116. The directory service112is an application that runs on an operating system on the server110. Directory service112is configured to interact with the server110in order to communicate with the anti-malware application106. In the present example, the directory server112receives file identification information from the anti-malware application106, such as a hash code, file path, version, and architecture information corresponding to a file stored on the client102. In the present example, the file is configured to be executed on a particular architecture. For example, architectures may include 32-bit or 64-bit architectures, INTEL x86 or POWERPC architectures, and so forth. The architecture information for the file may be determined using an API function.

The directory service112is also structured to request and receive files from the anti-malware application106. In some examples, if anti-malware application106is unable to match a hash code of a file with a hash code in the local data store of the client102, then the anti-malware application106is configured to send the file to directory service112for analysis.

The directory service112is coupled to a directory service registry114. In some examples, the directory service registry114is a database such as an SQL-compliant database. In other examples, the directory service registry114is another type of data store, such as a flat file or a web service. In the present example, the directory service registry114is stored on the server110. In other examples, the directory service registry114is stored on a data storage device separate from the server.

The directory service registry114is structured to store file identification information pertaining to files stored on one or more clients (e.g., client102). File identification information may include hash codes corresponding to files, a file counter that tracks a number of clients (or number of users) that have each particular file, and the malware risk value corresponding to each file. In some examples, the number of clients that “have” each particular file is the number of clients that have sent file identification information to the server and are matched to the file identification information that is stored on the server regarding that file. In some examples, the malware risk value is identified as a probability. In other examples, the malware risk value is identified by a string or a number corresponding to a risk level.

The directory service registry112may structure the file identification information by organizing or grouping the data according to the file to which the data corresponds. The directory service registry114may also store account information pertaining to each client (e.g., client102), or to individual users of each client. In other examples, account information may be stored separately. Accordingly, directory service112may access account information in order to uniquely identify clients that are connecting to the server. Accordingly, the number of clients having a file may be incremented based on the number of unique clients (or users) that have contacted the server regarding the file.

In the present example, server110is structured with an anti-malware scanner116. In some examples, server110is structured with a plurality of anti-malware scanners that together or separately scan files for malware. In the examples where the server has a plurality of anti-malware scanners, server110may receive files from clients (e.g., client102) and scan the files using the one or more anti-malware scanners. The results from the anti-malware scanner may be aggregated in order to determine a malware risk value corresponding to the file. The directory service112is communicatively coupled to anti-malware scanner116, such that directory service112receives a malware risk value determined for each file and stores the malware risk value associated with each file in the directory service registry114.

System architecture110allows for information gathering and malware scanning at a server110. The server110is able to take advantage of information from a plurality of clients in order to more accurately detect malware. For example, a large number of clients that have the same file installed may be indicative that the file does not have malware. Divesting of malware scanning from the client102and placing the scanning functionality on the server110results in fewer resources being used for malware scanning on the client102. Accordingly, the client102may realize performance gains.

FIG. 2is a flow diagram illustrating malware detection, according to an example of the present disclosure. The method200may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic and microcode), software (such as instructions run on a computer system, specialized hardware, dedicated machine, or processing device), firmware, or a combination thereof.

At block202, an anti-malware application is executed on a client machine, such that the anti-malware application is running as a background process on the client machine. In the present example, the anti-malware application is executed during the operating system boot process in order to provide malware protection prior to running user applications. In other examples, the anti-malware application may be executed prior to or after booting the operating system. The running anti-malware application is triggered on the client based on detection of specified file activities. In the present example, the specified activities may be user-configured, and include activities such as an attempt to install and/or execute a file. In other examples, the detected activities also include an attempt to download a file.

At block204, the client attempts to install a file. The attempt to install the file triggers the anti-malware application, prior to installing the file. Accordingly, the client is able to make a determination for whether to approve the file for installation using the following steps.

At block206, the anti-malware application determines a hash code for the file that the client is attempting to install. For example, the anti-malware application may determine an MD5 or SHA hash code for the file. In other examples, if an installation is for a plurality of files, the anti-malware application may determine a hash code corresponding to each file in the plurality of files.

At block208, the anti-malware application determines a file path corresponding to the file, a version for the file, and the architecture on which the file is configured to run. For example, if the installation path for the file is the “c:\program files\folderA\folderB” directory, then the determined file path may be “c:\program files\folderA\folderB.” In other examples, the file path may also include the name of the executable file that is stored in the file path. The version and architecture information may be determined by calling one or more API functions. The determined information corresponding to the file, such as the file path, version, and architecture may be referred to as file identification information. The file identification information may include one or more of the file path, version, and architecture. In other examples, file identification information includes additional information, such as a hash code corresponding to the file.

At block210, the file identification information is sent from the anti-malware application running on the client to a directory service application running on a server. The file identification information may be sent to the server in a tuple format. For example, the tuple may be a comma separated list of file identification information such as (file path, version, architecture). Other file identification information, such as the hash code of the file may additionally be sent to the server in the tuple or separately. In the present example, the server is a remote server that the client connects to over the Internet. In some examples, the server is associated with clients belonging to a particular local area network.

At block212, the directory service performs a matching between the received file path and one or more file paths that are stored in a directory service registry on the server. The matching may be performed by first querying the directory service registry with the received file path to identify any matching file paths stored in the directory service registry. In the present example, the directory service registry includes one or more file identification entries, each entry having an associated file path. Each of the one or more file identification entries may correspond to a particular file. If the file path is determined to be a match with a stored file path entry of one of the file identification entries, processing continues at block219.

At block214, if there is no match between the received file path and the stored file paths associated with the one or more file identification entries, then the directory service requests the file from the client, where the file is the file that the client is attempting to install.

At block216, the server receives the file from the client. The directory service application triggers an anti-malware scan of the file by one or more anti-malware scanner applications. An anti-malware scanner application may include, for example, commercial or proprietary anti-virus software. In the present example, each anti-malware scanner application returns a malware risk value associated with the received file. If there are more than one anti-malware scanners, the malware risk value determined by each scanner may be normalized and aggregated by the directory service. Malware risk value may be represented by a malware probability, a malware ratio or some other score or value representing the risk that the file includes malware.

At block218, the directory service creates an entry for the file in the directory service registry. The entry is stored as a file identification information entry and may include one or more of the malware risk value corresponding to the file, the hash code corresponding to the file, the file counter that tracks the number of clients that have the file installed, and the file path corresponding to the file. Upon creating the entry, the file counter may default to “1.” Upon detecting further installations of the file by other users, the directory service may increment the file counter to accurately reflect the number of clients who have the file. The directory service may also update the anti-malware scanner applications, such as by updating signature files of the anti-malware scanner applications, and periodically scan the file at a user-configured interval using the updated anti-malware scanner applications in order to update the malware risk value associated with the file.

Once the file a new file identification information entry has been created for the file, processing continues at block220.

At block219, the hash code, version, and architecture of the received file identification information is compared with the hash code, version, and architecture, respectively, of the file identification entries stored in the directory service registry. The comparing may be performed using a query of the directory service registry. A degree of match between one or more of the received hash code, version, and/or architecture information may be used to modify the risk score. In some examples, the processing continues at220if an exact match is detected between one or more of the hash code, version, and architecture information. In other examples, a partial match is sufficient. In yet other examples, a match is detected if there is an exact match with respect to all of the hash code, version, and architecture information. If a match is not detected, processing continues at block214. Based on determining a match, the file counter in the matching entry in the registry is incremented.

At block220, the hash code, file counter and malware risk value is retrieved from the file identification information entry in the directory service registry that is determined to be a match with the received file identification information. The file identification information entry that is a match may be referred to as a second file identification information entry. The data may be retrieved using a data search or other data lookup function. The data may be retrieved in a comma separated tuple format, such as: (hash code, file counter, malware risk value).

At block222, the directory service determines a risk score from the data retrieved from the file identification information entry. In the present example, the risk score is modified by a file path score modifier as well. For example, the degree of match between the received file path and the stored file path may be represented by a file path score modifier, which is taken into account along with the file counter and malware risk value. The risk score may be determined using one or more functions. In the present example, the risk score is initialized at “0.” The risk score is then modified by the file path score modifier, the file counter score modifier, and the malware risk score modifier in order to determine the risk score. The file counter score modifier and the malware risk score modifiers may be normalized values derived from the file counter and malware risk value retrieved from the file identification information entry. A normalized value may be determined by weighting the value, such as by multiplying or adding a constant to the value.

At block224, data such as the risk score and the hash code associated with the file identification information entry is sent to the client. In some examples, the risk score and hash code are sent as a tuple. In other examples the risk score and hash code are sent separately. The hash code may be stored in a local data store on the client in order to use the hash code for future comparisons. For example, when a file is executed, the hash code of the file may be matched to the hash code in the local data store in order to determine that the file is allowed to execute. In other examples, the risk score may be sent to the client without sending the hash code to the client. For example, a client may use the hash code determined on the client rather than a hash code sent from the server. In other examples, additional information pertaining to the file may also be sent to the client. The information is received by the anti-malware application running on the client for processing.

At block226, the anti-malware application presents the risk score on the client machine. In some examples, the risk score and user selection option is presented using a dialog that is displayed on a graphical user interface (GUI). In other examples, the risk score and user selection options may be presented via a command line interface.

At block228, a user may review the risk score and select an option to continue with the file installation, or the user may select an option to abort the file installation. For example, the risk score may indicate to the user that there is a high probability of malware, and therefore the user may elect to cancel the file installation.

In other examples, the risk score and the selection may be presented to the user if the risk score exceeds a threshold, but not if the risk score does not exceed the threshold. For example, if the risk score does not exceed the threshold, then the file may automatically install without presenting the risk score and/or requesting additional user selections.

FIG. 3is a flow diagram illustrating file path matching, according to an example of the present disclosure. The method300may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic and microcode), software (such as instructions run on a computer system, specialized hardware, dedicated machine, or processing device), firmware, or a combination thereof.

At block302, the file path received from the client is processed by a directory service on a server. In the present example, the file path is input into a matching function to identify a match, and if a match is detected, a degree of match.

At block304, the received file path is matched with stored file paths associated with one or more file identification information entries that are stored in a directory service registry. In some examples, the matching may include a brute-force character by character matching with each of the stored file paths. In other examples, the matching may include performing one or more other string matching algorithms for performing exact or fuzzy string matching.

At block306, if a match is detected between the received file path and a stored file path, the file identification information entry associated with the detected match is returned to the directory service. For example, the received file path may be “c:\program files\folderA\folderB” and a file identification information entry in the directory service registry may have a stored file path that exactly matches the received file path. Accordingly, the file identification information entry with the matching file path is returned to the directory service.

At block308, if no match between the received file path and the stored file paths is detected, then a portion of the received file path may be removed from the received file path. In some examples, the portion of the received file path is removed from the beginning of the received file path. For example, if the received file path is “c:\program files\folderA\folderB” then the received file path may be modified to “program files\folderA\folderB” by removing the “c:\” sub-string from the beginning of the received file path. The size of the portion to remove may be based upon detecting delimiters in the received file path, such as the “\” character. For example, removal of a first portion may remove the portion up to a first delimiter character. In another example, removal of a first portion may remove the portion up to and including a first delimiter character. In other examples, portions of a stored file path may be similarly removed.

At block310, a file path score modifier is adjusted. In the present example, a file path score modifier is initialized at “0” and incremented for each portion of the file path that is removed. In some examples, when the first portion of the file path is removed, the file path score modifier is incremented to “1.” In other examples, instead of incrementing the file path score modifier, the file path score modifier may be adjusted by another operation, such as by decrementing the file path score modifier.

After adjusting the file path score modifier and received file path, the received file path is compared with the stored file paths at block304. If there is a match, then at306the file identification information entry with the stored file path that matches the received file path is returned to the directory service.

If no match between the received file path and the stored file paths is detected, then at block308a portion of the received file path is removed. For example, if the received file path is “program files\folderA\folderB,” then the received file path is modified to “folderA\folderB” by removing the “program files\” sub-string from the beginning of the received file path.

At block310, the file path score modifier is further adjusted based on the additional removal of another portion of the file path. For example, if the file path score modifier is at “1,” then at block310the file path score modifier may be incremented to “2.” In some examples, the file path score modifier is equal to the number of sub-strings removed.

Upon adjusting the file path score modifier, the method returns to block304, and the method continues until either there is a match found or there is no portion of the received file path left to be removed. If there is a match found, then the file identification information entry associated with the detected match is returned to the directory service along with the file path score modifier. If there is no portion of the received file path left to be removed, then at block306the directory service identifies that there is no match between the received file path and any of the stored file paths.

FIG. 4is a flow diagram illustrating score determination, according to an example of the present disclosure. The method400may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic and microcode), software (such as instructions run on a computer system, specialized hardware, dedicated machine, or processing device), firmware, or a combination thereof.

At block402, the directory service begins the method to determine a risk score associated with file that the user is attempting to install. The method may be performed by inputting data such as a file path score modifier, malware risk score modifier, and file counter score modifier into a function.

At block404, the risk score is modified by the file path score modifier. For example, if there were two portions of the file path removed in order to match with the stored file path, then the file path score modifier may be “2.” The file path score modifier may be further adjusted using a constant value, such as by multiplying the file path score modifier by a constant in order to normalize the file path score modifier. In some examples, the risk score is initialized to “0.” Therefore, the adding of the file path score modifier to the risk score may be an adding of the file path score modifier to “0.”

At block406, the risk score is modified using the malware risk score modifier. The malware risk is retrieved from the file identification information entry that has a file path that is determined to be a match with the received file path. In some examples, the malware risk may be normalized by multiplying the malware risk by a constant value to determine a malware risk score modifier. In some examples, the malware risk score modifier modifies the risk score by adding the malware risk score modifier to the risk score.

At block408, the risk score is modified using the file counter score modifier. The file counter is retrieved from the file identification information entry that has a file path that is determined to be a match with the received file path. In some examples, the file counter is normalized by multiplying the file counter by a constant value to determine a file counter score modifier. In some examples, the file counter score modifier modifies the risk score by, for example, multiplying the file counter score modifier by the risk score.

In some examples, a formula for determining a risk score using the file path score modifier, the malware risk score modifier and the file counter score modifier may be as follows:

Risk score=(A*(file path score modifier)+B*(malware risk score modifier))*(C*file counter score modifier), where A, B, C are constants used to normalize the values.

At block410, the risk score is returned to the directory service, where the risk score is then sent to the client.

Exemplary computer system500includes processing device (processor)502, main memory504(e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM), double data rate (DDR SDRAM), or DRAM (RDRAM), and so forth), static memory506(e.g., flash memory, static random access memory (SRAM), and so forth), and data storage device518, which communicate with each other via bus530.

Processor502represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like.

More particularly, processor502may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. Processor502may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. Processor502is configured to execute instructions for performing the operations and steps discussed herein.

Computer system500may further include network interface device508.

Computer system500also may include video display unit510(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), alphanumeric input device512(e.g., a keyboard), cursor control device514(e.g., a mouse), and signal generation device516(e.g., a speaker).

Data storage device518may include a computer-readable storage medium on which is stored one or more sets of instructions (e.g., software) embodying any one or more of the methodologies or functions described herein. The instructions may also reside, completely or at least partially, within main memory504and/or within processor502during execution thereof by computer system500, main memory504and processor502also constituting computer-readable storage media. The instructions may further be transmitted or received over network520via network interface device508.

While data storage device518is shown in an example to be a single medium, the term “data storage device” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions.

The term “computer-readable storage medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure. The term “computer-readable storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, and magnetic media.

Some portions of the detailed description have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.