Patent Application
20070162975
The constant progress of communication systems that connect computers, particularly the explosion of the Internet and intranet networks, has resulted in the development of a new information era. With a single personal computer, a user may obtain a connection to the Internet and have direct access to a wide range of resources, including electronic business applications that provide a wide range of information and services. Solutions have been developed for rendering and accessing a huge number of resources. However, as more computers have become interconnected through various networks such as the Internet, abuse by malicious computer users has also increased. As a result, computer systems that identify potentially unwanted software have been developed to protect computers from the growing abuse that is occurring on modem networks.
It is estimated that four out of five users have potentially unwanted software on their personal computers. Those skilled in the art and others will recognize that potentially unwanted software may become resident on a computer using a number of techniques. For example, a computer connected to the Internet may be attacked so that a vulnerability on the computer is exploited and the potentially unwanted software is delivered over the network as an information stream. These types of attacks come in many different forms including, but certainly not limited to, computer worms, denial of service attacks and the like, all of which exploit one or more computer system vulnerabilities for illegitimate purposes. Also, potentially unwanted software may become resident on a computer using social engineering techniques. For example, a user may access a resource such as a Web site and download a program from the Web site to a local computer. While the program may be described on the Web site as providing a service desirable to the user; in actuality, the program may perform actions that are malicious or simply undesirable to the user. While those skilled in the art will recognize that potentially unwanted software may take many different forms, for purposes of the present invention and for simplicity in description, all potentially unwanted software will be generally referred to hereinafter as computer malware or, more simply, malware. As described herein, computer malware includes, but is certainly not limited to, spyware, ad-ware, viruses, Trojans, worms, RootKit, or any other computer program that performs actions that are malicious or not desirable to the user.
When a malware becomes resident on a computer, the adverse results may be readably noticeable to the user, such as system devices being disabled; applications, file data, or firmware being erased or corrupted; the computer system crashing or being unable to perform normal operations. However, some malware performs actions that are covert and not readily noticeable to the user. For example, spyware typically monitors a user's computer habits, such as Internet browsing tendencies, and transmits potentially sensitive data to another location on the network. The potentially sensitive data may be used in a number of ways, such as identifying a commercial product that matches the observed tendencies of the user. Then the spyware may be used to display an advertisement to the user that promotes the identified commercial product. Since the advertisement interrupts the normal operation of the computer, the actions performed by the spyware may not be desirable to the user.
Under the present system of identifying and addressing malware, computers are susceptible to being attacked in certain circumstances. For example, there is a period of time, referred to hereafter as a vulnerability window, that exists between when a new computer malware is released on the network and when antivirus software or an operating system component may be updated to protect the computer system from the malware. As the name suggests, it is during this vulnerability window that a computer system is vulnerable, or exposed, to the new computer malware.
At some point after the new computer malware is circulating on the network, an operating system provider and/or the antivirus software provider detects the new computer malware, as indicated by event 106. Once the computer malware is detected, the operating system and antivirus software providers may begin the process of reverse engineering the malware and creating a software update to recognize and/or protect against the computer malware. As a result of this effort, at event 108 the operating system provider and/or the antivirus software provider release an update that addresses the computer malware. Subsequently, at event 110 the update is installed on a user's computer system, thereby protecting the computer system and bringing the vulnerability window 104 to a close.
As can be seen from the examples described above, which are only representative of all of the possible scenarios in which computer malware poses security threats to a computer system, a vulnerability window 104 exists between the times that a computer malware 112 is released on a network and when a corresponding update is installed on a user's computer system. Those skilled in the art and others will recognize that the longer a vulnerability window exists, the greater the number of networked computers will be infected by the released malware. Thus, methods for quickly identifying new malware propagating on a communication network and initiating the process of creating a software update to protect against the new malware, may prevent vast numbers of networked computers from being infected.
Generally described, embodiments of the present invention are directed at efficiently collecting data this useful in developing software systems for identifying and protecting against malware. In accordance with one embodiment, a method for collecting data to determine whether a malware is propagating in a networking environment is provided. More specifically, the method includes receiving preliminary data sets at a server computer from a plurality of client computers that describes attributes of a potential malware. Then a determination is made regarding whether secondary data is needed to implement systems for protecting against the potential malware. If secondary data is needed, the method causes the secondary data to be collected when an additional preliminary data set is received from a client computer.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
The foregoing aspects and many of the attendant advantages of this invention will become more readily appreciated as the same become better understood by reference to the following detailed description, when taken in conjunction with the accompanying drawings, wherein:
Aspects of the present invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally described, program modules include routines, programs, applications, widgets, objects, components, data structures, and the like that perform particular tasks or implement particular abstract data types. Moreover, the present invention will typically be implemented in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located on local and/or remote computer storage media.
Embodiments of the present invention described herein are directed at efficiently collecting data that is useful in identifying and protecting against malware. In this regard, when a program (hereinafter referred to as “potential malware”) is scheduled to be added to an extensibility point on a computer associated with a user, a preliminary set of data that includes, among other things, a unique signature of the potential malware is transmitted to a server computer that is associated with a trusted entity. In any event, the preliminary set of data will typically be collected at a central location and aggregated together for the purpose of identifying “highly suspicious” potential malware. Then, when the highly suspicious potential malware is again encountered on a computer in the networking, more detailed secondary data may be collected. Among other things, the secondary data may include an actually binary or executable of the potential malware that allows developers to “reverse engineer” the potential malware. When an actual binary of the potential malware is reverse engineered, a signature that prevents the potential malware from continuing to spread on the communication network may be developed. By using this type of tiered system to collect data about programs being installed in a networking environment, the use of network resources (e.g., network bandwidth, and the like) expended in collecting data to identify new malware is minimized.
While the present invention will primarily be described in the context of collecting data for the purpose of identifying new malware released on a communication network, those skilled in the relevant art and others will recognize that the present invention is also applicable to other areas than those described. In any event, the following description first provides a description of an environment and system in which aspects of the present invention may be implemented. Then a method that implements aspects of the invention is described. The illustrative examples described herein are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Similarly, any steps described herein may be interchangeable with other steps or combinations of steps in order to achieve the same result.
The following discussion is intended to provide a brief, general description of a networking environment 200 suitable to implement aspects of the present invention. As illustrated in
For the sake of convenience,
When software that performs the functions of the present invention is implemented in a networking environments, such as the networking environment 200 illustrated in
In accordance with one embodiment, client-based software that implements aspects of the present invention is used to monitor Auto-Start Extensibility Points (“ASEPs”) on computers associated with users. Those skilled in the art and others will recognize that ASEPs refer to extensibility points that may be “hooked” to allow application programs to be auto-started without explicit user invocation. Embodiments of the present invention monitor a plurality of ASEPs to identify potential malware that will be executed as a result of changes made to an ASEP. Generally described, a potential malware that is added to an ASEP either automatically begins execution without user invocation (e.g., the WINDOWS EXPLORER® program in the MICROSOFT® WINDOWS operating system) or “hooks” into a program that is commonly executed by users (e.g., an internet Web browser program). ASEPs can be viewed in two ways: (1) as “hooks” (i.e., extensions) to existing auto-start application programs or (2) as standalone software applications that are registered as operating system auto-start extensions, such as an NT service in the MICROSOFT WINDOWS operating system, or as a daemon in UNIX-based operating system. Examples of known types of application programs that are commonly added to an ASEP include Browser Helper Objects (“BHOs”) and Layered Service Providers (“LSPs”).
When a potential malware is scheduled to be added to an ASEP on a client computer, a preliminary set of data that includes, among other things, a signature that uniquely identifies the potential malware may be transmitted to a server computer associated with a trusted entity. The preliminary set of data, in this embodiment, does not include all of the information that may be used by developers to identify and protect against malware. Instead, the preliminary set of data may be used to identify highly suspicious potential malware in which additional data should be collected. When highly suspicious potential malware is identified, the configuration of the server computer that is associated with the trusted entity is modified so that, when the highly suspicious potential malware is again encountered on a computer associated with a user, secondary data that further describes the potential malware is collected. For example, an additional set of data may include the actual binary or executable program that implements the potential malware. However, is should be well understood that aspects of the present invention allow secondary data to be obtained about any program that is encountered in the networking environment. Thus, the example of obtaining secondary data to identify malware should be construed as exemplary and not limiting.
As will be appreciated by those skilled in the art and others,
Now with reference to
With continuing reference to
In accordance with one embodiment of the present invention, a computer associated with a user maintains “client-based” software that implements aspects of the present invention. Conversely, a computer associated with the trusted entity maintains “server-based” software that implements additional aspects of the present invention. In the context of
As illustrated in
In instances when a signature generated from a potential malware that attempts to add itself to ASEP on the client computer 204 does not match a signature maintained in the signature database 306, the reporting module 304 informs the user that an application program is being installed on the client computer 204 and that configuration changes are scheduled to be made. Moreover, in one embodiment, the user is provided with an option to block installation of the potential malware. In instances when the user does not want the potential malware installed, the scheduled installation is prevented. Conversely, in instances when the user wants the potential malware installed, the scheduled installation proceeds without interference.
When a new signature is encountered that does not match a signature in the signature database 306, the reporting module 304 generates a preliminary set of data from the client computer 204 that may be used to analyze aspects of the potential malware. In this regard, a preliminary set of data is generated that is transmitted over the network 214 to the backend server 202 by the reporting module 304 where the data is stored in the backend database 212. As described in further detail below, when the preliminary set of data is received at the backend database 212, a determination may be made that secondary data should be collected. In this instance, the reporting module 304, is also responsible for generating the secondary data and transmitting this data to the backend server 202.
As further illustrated in
The backend server 202 illustrated in
Those skilled in the art and others will recognize that the backend server 202 and the client computer 204 illustrated in
Now with reference to
As illustrated in
At block 402, a preliminary set of data is generated on a client computer in which a potential malware attempted to add itself to an ASEP, at block 400. The preliminary set of data is used to catalog potential malware that are encountered on computers connected to a communication network. Moreover, as mentioned previously, the data generated on a client computer may be aggregated with data that is received from different computers to determine whether an application program that is being encountered on client computers is malware. In this regard, the preliminary set of data generated at block 402 includes, but is not limited to, a signature of the potential malware, file metadata, configuration data, and run-time attributes that identify the state of the computer. Moreover, the preliminary set of data includes an indicator or “vote” regarding whether the user allowed the potential malware to be installed on their computer. It should be well understood that the preliminary set of data generated at block 402 contains a minimal amount of information that consumes a small amount of network resources when transmitted to a remote computer.
At block 404, the preliminary set of data generated at block 402 is transmitted to a computer associated with a trusted entity. For example, data generated from a computer associated with a user (e.g., the client computer 204) may be transmitted over a network connection to the backend server 202 (
As further illustrated in
Now with reference to
Returning to
At decision block 410, the collection routine 300 determines whether the secondary data that will be collected includes a “malware activity report.” In one embodiment, if the “MALWARE ACTIVITY REPORT” 502 column of the backend database 212 contains a value which indicates that a malware activity report should be collected, the collection routine 300 proceeds to block 412. Conversely, if the appropriate value in the backend database 212 does not indicate that a malware activity report should be collected, the collection routine 300 proceeds to block 414.
At block 412, a malware activity report is obtained from the client computer that transmitted the preliminary set of data to the trusted entity at block 404. As mentioned previously, client-based software that is implemented by aspects of the present invention may be included in anti-malware software that is installed on a client computer. Those skilled in the art and others will recognize that some anti-malware software systems are configured to produce reports that describe behaviors observed on a computer that may be characteristic of malware. For example, software systems exist that record suspicious activities such as excess network activity, use of potentially dangerous resources, and the like. In any event, at block 412, data is transmitted to the client computer that indicates a malware activity report was requested. In response, software on the client computer causes the malware activity report to be transmitted to a server computer that is associated with a trusted entity.
At decision block 414, the collection routine 300 determines whether the secondary data that will be collected is a binary or executable that implements the potential malware. In one embodiment, if the “BINARY” 502 column of the backend database 212 contains a value which indicates that a binary of the appropriate potential malware should be collected, the collection routine 300 proceeds to block 416. Conversely, if the appropriate value in the backend database 212 does not indicate that a binary should be collected, the collection routine 300 proceeds to block 418.
At block 416, a binary or executable of the potential malware is obtained from the client computer that transmitted the preliminary set of data to the trusted entity at block 404. Those skilled in the art and others will recognize that each program capable of being executed on a computer may be represented in a binary format. Typically, anti-malware software performs a scan for malware by searching binary file(s) that implement the functionality of the potential malware. Thus, a binary that implements the potential malware is readily accessible from a client computer. In any event, at block 416, data is transmitted to the client computer that indicates a binary of the potential malware was requested. In response, software on the client computer causes one or more binary file(s) that implement the potential malware to be transmitted to a server computer associated with the trusted entity.
At decision block 418, the collection routine 300 determines whether the secondary data that will be collected is a memory dump of the current process. In one embodiment, if the “PROCESS MEMORY DUMP” 506, column of the backend database 212 contains a value which indicates that a memory dump of the current process associated with the potential malware should be collected, the collection routine 300 proceeds to block 420. Conversely, if the appropriate entry in the backend database 212 does not indicate that a memory dump of the current process should be collected, the collection routine 300 proceeds to block 422.
At block 420, a memory dump of the current process is obtained from the client computer and transmitted to a computer associated with a trusted entity. Those skilled in the art and others will recognize that a program, or component of a program, that is scheduled to be executed by a CPU on a computer is referred to as “process.” Moreover, multitasking between different processes may be performed by allocating time slices to individual processes and performing a context switch to a subsequently scheduled process when the time slice of an executing process expires. In any event, at block 416, an indicator is transmitted to the client computer that indicates a memory dump of the current process was requested. In response, software on the client computer causes the memory dump to be generated and transmitted to a server computer that is associated with the trusted entity.
At decision block 422, the collection routine 300 determines whether the secondary data that will be collected is a full crash dump. In one embodiment, if the “FULL CRASH DUMP” 508, column of the backend database 212 contains a value which indicates that a full crash dump should be collected, the collection routine 300 proceeds to block or 424. Conversely, if the appropriate entry in the backend database 212 does not indicate that a full crash dump should be collected, the collection routine 300 proceeds to block 426.
At block 424, a full crash dump that contains all the contents of physical memory is obtained from the client computer that transmitted the preliminary set of data to the trusted entity at block 404. Those skilled in the art and others will recognize that software systems exist for creating a full crash dump. For example, in some types of systems a crash dump is automatically generated when an error occurs in a computer. In these types of systems, developers use the data contained in the crash dump to identify the source of the error. Those skilled in the art and others will recognize that a full crash includes all the contents of physical memory and data that describes the state of the computer. As a result, with a full crash dump developers are able to use programs designed for de-bugging to perform an analysis of a potential malware. In any event, at block 424, an indicator is transmitted to the client computer that indicates a full crash dump was requested. In response, software on the client computer causes the full crash dump to be generated and transmitted to a server computer that is associated with the trusted entity.
As further illustrated in
At block 428, data items in the backend database 212 are updated to reflect that secondary data that is associated with a potential malware should be collected. As mentioned previously, when a signature that matches a potential malware is identified, a lookup is performed in the backend database 212. In this regard, a field in the backend database 212 may indicate that certain types of secondary data that is associated with a potential malware should be collected. Thus, after developers perform an analysis of the data that describes a potential malware, at block 426, the backend database 212 may be updated to reflect that additional data should be collected. For example, as mentioned previously, the data collected in the backend database 212 may indicate that a high percentage of users are preventing a program from being installed on their computer. Based on this type of information, developers may conclude that the program is malware. In this instance, to create a software update capable of removing the malware from a user's computer, developers may want to collect the actual “binary” program so that the malware may be reverse engineered. In order to obtain the “binary” program, the appropriate field in the backend database 212 may be updated to reflect that this secondary data is being requested. Then the collection routine 300 proceeds to block 430, where it terminates.
While illustrative embodiments have been illustrated and described, it will be appreciated that various changes can be made therein without departing from the spirit and scope of the invention.
