Systems and methods for preventing false positive malware identification

A computer-implemented method for preventing false positive malware identification may include (1) identifying a set of variants of a trusted software program, (2) characterizing, for each variant in the set of variants of the trusted software program, at least one common property of the variants, (3) clustering the set of variants of the trusted software program based on the common property of the variants, and (4) creating a signature capable of recognizing variants of the trusted software program. Various other methods, systems, and computer-readable media are also disclosed.

BACKGROUND

In recent years, authors of malicious software (“malware”) have attempted to proliferate malware by generating thousands or potentially millions of variations of malicious files. For example, unique versions of malware code may be created with each new infection, or the malware program may modify itself each time it propagates to a new computer system, or even every time it runs (so-called “polymorphic malware”). Unfortunately, because many existing antivirus technologies detect malware by detecting or identifying unique digital signatures or fingerprints associated with known-malicious files, malware authors may avoid detection by only distributing new (i.e., unique) or repacked versions of malicious files.

In light of this, some security-software vendors have begun investigating and implementing reputation-based security systems. In a reputation-based security system, a security-software vendor may attempt to determine whether a file represents malware by collecting, aggregating, and analyzing data from potentially millions of user devices within a community, such as the security-software vendor's user base. For example, by determining a file's source, age, and prevalence within the community, among other details, a security-software vendor may gain a fairly accurate understanding as to whether the file represents malware.

Some legitimate software publishers and distributors, however, also distribute many unique variants of a program. For example, a software developer may customize each copy of a program it distributes to personalize the user experience for each customer, or to facilitate detection of unauthorized copying of the software. A software distributor may also repackage freeware or “adware” programs with advertisements uniquely selected for each customer.

Unfortunately, malware detection systems that rely on signature-based detection may not recognize customized versions of a legitimate program as variants of a single program. In addition, reputation-based systems may incorrectly identify unique or similar versions of a program with low prevalence and unknown origin or age as potential polymorphic threats. These mistakes, known as “false positives,” may be extremely disruptive and costly for an enterprise since they can result in the deletion or removal of legitimate, and potentially essential, files and software from computing devices within the enterprise. Accordingly, the instant disclosure identifies and addresses a need for additional and improved systems and methods for preventing false-positive malware identification.

SUMMARY

As will be described in greater detail below, the instant disclosure generally relates to systems and methods for preventing false positive malware identification by identifying variants of a trusted program, identifying one or more common properties of the variants, clustering the variants based on the common properties, and creating a signature that may be used to recognize the clustered variants of the trusted program.

In one example, a computer-implemented method for preventing false positive malware identification may include (1) identifying a set of variants of a trusted software program, (2) characterizing, for each variant in the set of variants of the trusted software program, at least one common property of the variants, (3) clustering the set of variants of the trusted software program based on the common property of the variants, and (4) creating a signature capable of recognizing variants of the trusted software program.

In some examples, identifying the set of variants of the software program may include (1) obtaining, from a software distributor, at least one variant in the set of variants of the software program, (2) obtaining, from the software distributor, a description of the common property of the variants of the software program, and/or (3) obtaining, from a community of software users, the set of variants of the software program.

In one embodiment, the common property may include (1) a static code segment, (2) a behavioral property, and/or (3) a pattern of network communication. In some examples, characterizing the common property of each variant of the set of variants of the trusted software program may include analyzing a subset of variants in the set of variants to identify (1) the static code segments present within the subset of variants, (2) the behavioral property of the subset of variants, and/or (3) the pattern of network communication of the subset of variants.

In some examples, clustering the set of variants of the trusted software program may include (1) verifying the presence of the common property in a variant that is in the set of variants, but not in the subset, and (2) ascribing the common property to at least one variant that is in the set of variants, but not in the subset. In some examples, creating a signature based on the common property of the set of variants of the trusted software program may include (1) generating a signature hash capable of identifying variants of the trusted software program, (2) describing a behavioral property capable of identifying variants of the trusted software program, and/or (3) describing a pattern of network communication capable of identifying variants of the trusted software program.

In some examples, the computer-implemented method may further include adding the signature to a database that associates common property signatures with sets of variants of trusted software programs. In addition, the computer-implemented method may include (1) identifying a candidate software program, (2) identifying the trusted software program of which the candidate software program purports to be a variant, (3) querying, using the identification of the trusted software program, the trusted software program database, (4) receiving, in response to querying the trusted software program database, at least one common property signature associated with the trusted software program, and (5) identifying the candidate software program as a variant of the trusted software program by verifying that the common property of the set of variants of the trusted software program on which the common property signature is based is present in the candidate software program.

In one embodiment, the computer-implemented method may further include (1) identifying a candidate software program, (2) identifying a property of the candidate software program, (3) creating a signature based on the property of the candidate software program, (4) querying, using the signature, the trusted software program database, (5) receiving, in response to querying the trusted software program database, at least one common property signature associated with a trusted software program, and (6) identifying the candidate software program as a variant of the trusted software program by verifying that the common property of the set of variants of the trusted software program on which the common property signature is based is present in the candidate software program.

In one embodiment, a system for implementing the above-described method may include (1) an identification module, stored in memory, that identifies a set of variants of a trusted software program, (2) a characterization module, stored in memory, that characterizes, for each variant in the set of variants of the trusted software program, at least one common property of the variants, (3) a clustering module, stored in memory, that clusters the set of variants of the trusted software program based on the common property of the variants, (4) a signature module, stored in memory, that creates, based on the common property of the set of variants of the trusted software program, a signature capable of recognizing variants of the trusted software program, and (5) at least one processor configured to execute the identification module, the characterization module, the clustering module, and the signature module.

In some examples, the above-described method may be encoded as computer-readable instructions on a non-transitory computer-readable medium. For example, a non-transitory computer-readable medium may include one or more computer-executable instructions that, when executed by at least one processor of a computing device, may cause the computing device to (1) identify a set of variants of a trusted software program, (2) characterize, for each variant in the set of variants of the trusted software program, at least one common property of the variants, (3) cluster the set of variants of the trusted software program based on the common property of the variants, and (4) create, based on the common property of the set of variants of the trusted software program, a signature capable of recognizing variants of the trusted software program

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

The present disclosure is generally directed to systems and methods for preventing false positive malware identification. As will be explained in greater detail below, the systems and methods described herein may identify variants of a trusted program to prevent the program from being incorrectly identified as malware or suspected malware, potentially reducing the time and attention required of users or system administrators. In addition, these systems and methods may reduce the number of signatures necessary to provide anti-malware protection, potentially reducing the resources required to differentiate malware from trusted programs.

The following will provide, with reference toFIGS. 1-2B, detailed descriptions of exemplary systems for preventing false positive malware identification. Detailed descriptions of corresponding computer-implemented methods will also be provided in connection withFIGS. 3-5B. In addition, detailed descriptions of an exemplary computing system and network architecture capable of implementing one or more of the embodiments described herein will be provided in connection withFIGS. 6 and 7, respectively.

FIG. 1is a block diagram of an exemplary system100for preventing false positive malware identification. As illustrated in this figure, exemplary system100may include one or more modules102for performing one or more tasks. For example, and as will be explained in greater detail below, exemplary system100may include an identification module104that may identify a set of variants of a trusted software program. Exemplary system100may additionally include a characterization module106that may characterize, for each variant in the set of variants of the trusted software program, at least one common property of the variants. Exemplary system100may also include a clustering module108that may cluster the set of variants of the trusted software program based on the common property of the variants. Exemplary system100may additionally include a signature module110that may create a signature based on the common property of the set of variants of the trusted software program capable of recognizing variants of the trusted software program. Although illustrated as separate elements, one or more of modules102inFIG. 1may represent portions of a single module or application.

As illustrated inFIG. 1, exemplary system100may also include one or more databases, such as database120. In one example, database120may be configured to store trusted program data, which may include signatures capable of recognizing variants of trusted software program.

Database120may represent portions of a single database or computing device or a plurality of databases or computing devices. For example, database120may represent a portion of server206inFIGS. 2A-2B, computing system610inFIG. 6, and/or portions of exemplary network architecture700inFIG. 7. Alternatively, database120inFIG. 1may represent one or more physically separate devices capable of being accessed by a computing device, such as server206inFIGS. 2A-2B, computing system610inFIG. 6, and/or portions of exemplary network architecture700inFIG. 7.

Exemplary system100inFIG. 1may be implemented in a variety of ways. For example, all or a portion of exemplary system100may represent portions of exemplary system200inFIG. 2A. As shown inFIG. 2A, system200may include a computing device202in communication with a server206via a network204. In one example, computing device202may be programmed with one or more of modules102and/or may store all or a portion of the data in database120. Additionally or alternatively, as shown inFIG. 2B, server206may be programmed with one or more of modules102and/or may store all or a portion of the data in database120.

In one embodiment, one or more of modules102fromFIG. 1may, when executed by at least one processor of computing device202and/or server206, enable computing device202and/or server206to prevent false positive malware identification. For example, and as will be described in greater detail below, identification module104may be programmed to identify a set of program variants208of a trusted software program. In addition, characterization module106may be programmed to characterize, for each variant in the set of variants of the trusted software program, at least one common property210of the variants. Clustering module108may be programmed to cluster the set of variants of the trusted software program based on the common property of the variants to create program cluster212. Finally, signature module110may be programmed to create a common property signature214capable of recognizing variants of the trusted software program.

Computing device202generally represents any type or form of computing device capable of reading computer-executable instructions. Examples of computing device202include, without limitation, laptops, tablets, desktops, servers, cellular phones, Personal Digital Assistants (PDAs), multimedia players, embedded systems, wearable devices (e.g., smart watches, smart glasses, etc.), gaming consoles, combinations of one or more of the same, exemplary computing system610inFIG. 6, or any other suitable computing device.

Server206generally represents any type or form of computing device that is capable of storing, comparing, and/or providing data. Examples of server206include, without limitation, application servers and database servers configured to provide various database services and/or run certain software applications.

FIG. 3is a flow diagram of an exemplary computer-implemented method300for preventing false positive malware identification. The steps shown inFIG. 3may be performed by any suitable computer-executable code and/or computing system. In some embodiments, the steps shown inFIG. 3may be performed by one or more of the components of system100inFIG. 1, system200inFIGS. 2A-2B, computing system610inFIG. 6, and/or portions of exemplary network architecture700inFIG. 7.

As illustrated inFIG. 3, at step302one or more of the systems described herein may identify a set of variants of a trusted software program. For example, identification module104may, as part of computing device202and/or server206inFIGS. 2A-2B, identify a set of program variants208of a trusted software program.

The phrase “trusted software program,” as used herein, generally refers to a software program obtained from a reputable source and/or whose origin and/or integrity has been verified. For example, a software program obtained directly from a software publisher or authorized distributor with an established reputation may be considered a trusted software program. Similarly, a software program that has been digitally signed by a code signing certificate by a trusted entity may considered a trusted software program.

In addition, the term “program variant,” as used herein, generally refers to versions of a software program that differ in some respect from one another, but originate from the same code base, and are substantially identical in function. Program variants may, for example, have unique splash screens for each customer, embedded strings identifying the purchaser or licensee of the program, or segments of custom-developed code, and/or be designed specifically for each customer's computing infrastructure.

Identification module104may identify a set of variants of a software program in any suitable manner. For example, identification module104may obtain one or more variants of a software program from a software publisher or authorized distributor. In this example, identification module104may employ various measures for securely acquiring the program variants and/or verifying the integrity of the software program files received. For example, identification module104may retrieve the program variants from a network location controlled by a software publisher or distributor and/or protected by a password or other security measures.

In addition, and as mentioned previously, identification module104may use code signing certificates to verify both that the program files originated from a software publisher identified in the certificate and that the program has not been modified since it was digitally signed by the software publisher. As used herein, the phrase “code signing certificate” generally refers to any electronic document that is embedded in a software file and is used (e.g., with public key cryptography) to create a digital signature that binds a public key to the identity of a software publisher. Code signing certificates may be issued by a certificate authority that verifies the identity of the software publisher. Software publishers may also create their own code signing certificates. For example, a publisher may submit a public key to a certificate authority and retain a private key to be used in encryption. Software users may then obtain the public key, either from the publisher or the certificate authority, to verify that a code signing certificate originated from the software publisher. In some examples, certificate authorities may issue digital certificates for purposes other than code signing. However, a code signing certificate may contain fields indicating that the certificate is to be used only in code signing.

In another example, identification module104may obtain a description of the common property of the variants of the software program from a software developer or publisher. For example, a software developer or publisher may identify strings or code segments common to variants of the software program, and possibly including variants not yet created or released. Additionally or alternatively, a software developer or publisher may identify behavioral or network usage attributes of program variants. In another example, a software developer or publisher may generate and provide the signatures to be used in identifying variants of the software program.

In another example, identification module104may obtain a set of variants of a software program from a community of software users. Because obtaining program files from users may introduce points of security failure versus obtaining the program files directly from the software publisher, identification module104may take measures to assure the identity and reputation of the users providing the software files. For example, identification module104may use code analysis or behavioral testing tools to assure that the set of program variants does not include malware.

Returning toFIG. 3, at step304one or more of the systems described herein may characterize, for each variant in the set of variants of the trusted software program, at least one common property of the variants. For example, at step304characterization module106may, as part of computing device202and/or server206inFIGS. 2A-2B, characterize, for each variant in the set of program variants208of the trusted software program, at least one common property210of the program variants208.

Characterization module106may characterize the variants in the set of program variants in a variety of ways. For example, characterization module106may identify and describe one or more properties common to variants of the software program, such as static code segments, behavioral properties, and/or patterns of network communication. Characterization module106may also limit or expand on common properties identified by identification module104at step302ofFIG. 3in order to more accurately distinguish program variants from other software programs and/or to simplify the process (and thereby decrease the time required) to identify program variants. Since speed and accuracy of identification may represent conflicting goals, characterization module106may be configurable to favor either speed or accuracy.

In some examples, characterization module106may characterize the common property of each variant of the set of variants of the trusted software program by analyzing a subset of variants in the set of variants to identify common properties of the variant subset, such as those mentioned previously (namely, static strings or code segments, behavioral properties, and/or patterns of network communication). Since a set of program variants may include thousands of program files, analyzing a subset of the variant files may significantly reduce the time required to characterize the common properties of the variants.

Characterizing variants of a software program by analyzing a subset of the variants may be the first step of an inferential method of characterizing and clustering software program variants.FIG. 4depicts one embodiment of a method400for inferentially characterizing and clustering program variants that may be performed in accordance with steps304and306ofFIG. 3. At step402ofFIG. 4, characterization module106may analyze a subset of variants in the set of variants of the trusted software program to identify a common property of the set of variants. Subsequent steps of method400may be performed by clustering module108, as described in detail below.

Returning toFIG. 3, at step306one or more of the systems described herein may cluster the set of variants of the trusted software program based on the common property of the variants. For example, at step306clustering module108may, as part of computing device202and/or server inFIGS. 2A-2B, cluster the set of program variants208of the trusted software program based on the common property210of the variants, as characterized by characterization module106, to create program cluster212.

Clustering module108may cluster the set of variants of the trusted software program in a variety of ways. For example, clustering module108may cluster the set of program variants by verifying that the common property is present in each variant of the set of program variants. In other examples, clustering module108may cluster the set of variants of the trusted software program by inferentially characterizing and clustering the program variants, as shown inFIG. 4. For example, at step404ofFIG. 4, clustering module108may verify the presence of the common property (which may have been identified by characterization module106in step402) in a variant that is in the set of variants, but not in the subset. At step406, clustering module108may inferentially cluster variants of the software program by ascribing the common property to at least one variant that is in the set of program variants, but not in the subset. In some examples, clustering module108may verify the accuracy of the clustering process by verifying that the common property is present in the variant not in the subset, or in a randomly-selected sample of program variants not included in the subset.

Returning toFIG. 3, at step308one or more of the systems described herein may create, based on the common property of the set of variants of the trusted software program, a signature that is capable of recognizing variants of the trusted software program. For example, at step308signature module110may, as part of computing device202and/or server206inFIGS. 2A-2B, create, based on the common property210of the set of program variants208of the trusted software program, a common property signature214capable of recognizing variants of the trusted software program.

The term “signature,” as used herein, generally refers to any type or form of notation associated with a software program that may be used to identify a software program or file. A signature may be based on any of a variety of characteristics, including common attributes of variants of a software program (such as static strings or code segments), behavioral attributes (such as calling a specific operating system routine at identified points in the software program's operation), or network behavior (such as accessing network resources at specific points in the software program's operation).

Signature module110may create a signature based on one or more common properties of variants of the trusted software program in any suitable manner. For example, signature module110may create a signature by generating a signature hash capable of identifying variants in the set of variants of the trusted software program. The phrase “signature hash,” as used herein, generally refers to any numeric or alphanumeric string generated by a hash function that may be used to identify variants of a software program. Since software program variants, by definition, are not identical, identifying variants of a software program using a signature hash may depend on applying the hash function to strings or code segments common to the variants.

In another example, signature module110may create a signature describing a behavioral property and/or a pattern of network communication common to variants of the trusted software program. While the use of signature hashes is the most commonly used method used by malware detection systems for identifying malware programs, using behavioral or network communication properties may, in some instances, be a more accurate or less computationally complex method for identifying software programs, particularly in the case of trusted software programs, where behavioral or network communication properties may be reliably known or verified by the software developer. In some examples, signature module110may apply methods used for creating computational or network behavior signatures capable of identifying malware programs when creating signatures for identifying variants of trusted software programs.

In some examples, the systems described herein may add the signature to a database that associates common property signatures with sets of variants of trusted software programs. For example, at step308signature module110may, as part of computing device202and/or server206inFIGS. 2A-2B, add common property signature214to trusted program data122in database120on server206. In some examples, trusted program data122may be part of a “whitelist” for use by a malware detection system.

In some embodiments, the systems described herein may identify a variant of a trusted software program as part of a malware scan of a data store by verifying that a software program tentatively identified as a trusted software program contains a common property of variants of the trusted program.FIG. 5Ais a flow diagram of an exemplary method500for identifying variants of a trusted software program. At step502ofFIG. 5A, one or more of the systems described herein may identify a candidate software program, and at step504, identify the trusted software program of which the candidate software program purports to be a variant. For example, the candidate program may be tentatively identified as a trusted software program based on the file name or location in the directory structure of a data store.

At step506ofFIG. 5A, database module112ofFIGS. 2A-2Bmay query, using the tentative identification of the trusted software program, the trusted software program database120and, at step508ofFIG. 5A, receive, in response to querying the trusted software program database120, at least one common property signature associated with the trusted software program. Using the common property signature, signature module110ofFIGS. 2A-2Bmay identify the candidate software program as a variant of the trusted software program by verifying that the common property of the set of variants of the trusted software program represented by the common property signature is present in the candidate software program. For example, the candidate program may be identified as a variant of the trusted software program by calculating a signature hash of strings or code segments in the candidate program and comparing the calculated signature hash to the signature hash associated with variants of the trusted software program.

In other embodiments, the systems described herein may identify a variant of a trusted software program by creating a signature based on a property of a software program and verifying that the signature is a signature of a common property of variants of a trusted program.FIG. 5Bis a flow diagram of an exemplary method550for identifying variants of a trusted software program. At step552ofFIG. 5B, one or more of the systems described herein may identify a candidate software program, and at step554ofFIG. 5B, identify a property of the candidate software program. At step556ofFIG. 5B, signature module110ofFIG. 2Amay create a signature based on the property of the candidate software program. For example, signature module110may calculate a signature hash of strings or code segments present in the candidate software program.

At step558ofFIG. 5B, database module112ofFIGS. 2A-2Bmay query, using the calculated signature, trusted software program database120, and at step560, receive, in response to querying the trusted software program database120, at least one common property signature associated with a trusted software program. At step562ofFIG. 5B, signature module110may identify the candidate software program as a variant of the trusted software program by verifying that the common property of the set of variants of the trusted software program represented by the common property signature is present in the candidate software program.

As detailed above, the systems and methods described herein may prevent false positive malware identification in part by applying methods used for identifying malware to identifying trusted software programs. For example, by clustering variants of trusted programs based on common properties of variants of the software program, the systems and methods described herein may reduce the time and resources required to scan large data stores for malware and/or may reduce false positive malware identifications, which may require the time and attention of a user or administrator to resolve.

Furthermore, by generating a generic signature to describe a cluster of malware samples, these systems and methods may reduce the number of signatures necessary to provide anti-malware protection, potentially reducing the resources needed to propagate, store, and use signatures. Additionally, these systems and methods may efficiently cluster variants of trusted programs to minimize the computational complexity necessary to identify trusted program variants.

As detailed above, computing system610and/or one or more components of network architecture700may perform and/or be a means for performing, either alone or in combination with other elements, one or more steps of an exemplary method for preventing false positive malware identification.

In addition, one or more of the modules described herein may transform data, physical devices, and/or representations of physical devices from one form to another. For example, one or more of the modules described herein may transform a computing system into a computing system for clustering variants of trusted software programs and/or analyzing software programs to identify variants of trusted software programs. As another example, one or more of the modules recited herein may receive variants of trusted software programs, transform the program variants to signatures capable of recognizing program variants, and use the result of the transformation to recognize variants of trusted software programs. Additionally or alternatively, one or more of the modules recited herein may transform a processor, volatile memory, non-volatile memory, and/or any other portion of a physical computing device from one form to another by executing on the computing device, storing data on the computing device, and/or otherwise interacting with the computing device.