Programmatic communication in the event of host malware infection

A distress signal sender and a distress signal receiver receive beacon-name generation parameters and generate a beacon name based at least in part on the received parameters, the beacon name representing a network location. Responsive to detecting an unexpected lack of access to network communications, the distress signal sender sends a beacon message to the generated beacon name, the beacon message describing a security state of the client. The distress signal receiver detects the beacon message sent by the distress signal sender, and responsive to receiving the beacon message, performs a remedial action.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention pertains in general to computer security, and more specifically, to identifying infected machines in the presence of communications-blocking malware.

2. Description of Related Art

Modern computer systems are often susceptible to a number of different problems, problems which are exacerbated by the increasing complexity of such systems. One such problem relates to system security. There exists a wide variety of security threats posed by malicious software such as viruses, worms, Trojan horses, and the like—collectively referred to as “malware”—that secretly performs operations not desired by the computer user. Such operations include theft of important data (e.g. financial records), modification or destruction of system or user files, execution of “backdoor” programs, and the like. The automated identification of host systems infected by malware is desirable, and this is particularly so for enterprises having a large number of computer systems, for which manual examination of every system is infeasible. Such automated identification typically relies on an infected host to recognize its infection and to report the infection to some other system, such as a security server, Administrator Console, or the like, from which some form of aid can be expected.

However, one possible action of malware is to interrupt communications from an infected host system to other systems, such as those having uniform resource locators (URLs) or internet protocol (IP) addresses on a list of common anti-malware security providers. Thus, without the ability of the host to advertise the fact that it is infected with malware, it becomes considerably more difficult to identify hosts requiring attention.

SUMMARY

The difficulties described above are addressed by a computer-implemented method, computer readable medium, and computer-implemented device that employ beacon names—e.g., URLs or IP addresses, chosen to represent non-typical network destinations—as the destination addresses when sending messages within an enterprise network, thereby thwarting malware expecting the use of well-known addresses. Parameters are distributed by a security server to sending components located on client devices and to receiving components located elsewhere within the enterprise, and the beacon names are generated based at least in part on the distributed parameters. In one embodiment, the sending and receiving components synchronously generate additional beacon names at well-defined intervals, without requiring redistribution of parameters by the security server. In another embodiment, a sending component sends a distress signal message (or “beacon”) in response to unexpected lack of client device access to network resources, and a receiving component upon detecting the beacon takes a remedial action to address possible presence of malware on the client device. In still another embodiment, the sending component sends a message periodically while the client device continues to have expected network access, and the receiving component takes a remedial action in response to failure to receive a message from the client device for a given period of time.

One embodiment of the computer-implemented method receives, at a client, beacon name-generation parameters, and generates a beacon name based at least in part on the received parameters, the beacon name representing a network location. The method additionally stores the beacon name, and sends a beacon message to the beacon name, the beacon message describing a security state of the client.

Embodiments of the computer-readable storage medium store a computer program executable by a processor for responding to a client indication of malware infection. Actions of the computer program comprise receiving beacon name-generation parameters, and generating a beacon name based at least in part on the received parameters, the beacon name representing a network location. The actions further comprise detecting a beacon message sent by a client device and addressed to the beacon name, the beacon message describing a security state of the client device, and, responsive to receiving the beacon message, performing a remedial action.

A computer-implemented system for responding to a client indication of malware infection comprises a beacon name information repository and a distress signal receiver module. The distress signal receiver module performs actions comprising receiving beacon name-generation parameters, and generating a beacon name based at least in part on the received parameters, the beacon name representing a network location. The actions further comprise storing the received parameters and the generated beacon name in the beacon name information repository, and detecting a beacon message sent by a client device and addressed to the beacon name, the beacon message describing a security state of the client device. The actions further comprise, responsive to receiving the beacon message, performing a remedial action.

DETAILED DESCRIPTION

System Architecture

FIG. 1is a block diagram of an enterprise permitting communication in the presence of communication-blocking malware, in accordance with one embodiment of the present invention. Enterprise105encompasses the computer systems under the control of a particular organization, such as a corporation, a school, a governmental body, and the like. In particular, the enterprise105ofFIG. 1comprises one or more clients110and a security server120, communicatively coupled by a network140. The enterprise105can have thousands or millions of clients110and security servers120.

A client110receives security services, such as malware security updates for its anti-malware software, from the security server120. The security server120is depicted inFIG. 1as being located within the enterprise, but in some embodiments the security server is located outside of the enterprise and administered by an organization other than that administering the enterprise105. The client110may be infected by malware that blocks communications of the client with some or all other devices. Typically, the malware blocks only communications with security servers whose names, such as hostnames, uniform resource locators (URLs) or internet protocol (IP) addresses, are on a list of known security providers. This selective blocking allows the malware to conceal its presence more effectively, since blocking all communications would alert users that something was amiss and prompt them to investigate. The client110communicates with the security server120over the network140via a beacon name—e.g., a URL or IP address—agreed upon by the client and the server. The beacon name is selected so as not to appear on a list of known names of security providers, thus preventing any malware that might be present on the client110from blocking the communications from the client to the beacon name. In one embodiment, this is accomplished by generating the beacon name using a pseudo-random algorithm. The beacon name represents a network location in that it acts as a destination address for network communications, although a given beacon name would likely not be considered a valid destination on a conventional network, particularly in embodiments in which the beacon name is generated according to a pseudo-random algorithm. The client110and security server120are described in more detail, below, in association withFIGS. 3 and 4, respectively.

The network140represents the communication pathways between the clients110and the security server120. In one embodiment, the clients110and the security server120are located completely within the enterprise105; in other embodiments, some components, such as components used by the security server120, are located outside the enterprise105but accessed as services via the network140. In one embodiment, the network140uses standard Internet communications technologies and/or protocols. Thus, the network140can include links using technologies such as Ethernet, 802.11, integrated services digital network (ISDN), asynchronous transfer mode (ATM), etc. Similarly, the networking protocols used on the network140can include the transmission control protocol/Internet protocol (TCP/IP), the hypertext transport protocol (HTTP), the simple mail transfer protocol (SMTP), the file transfer protocol (FTP), etc. The data exchanged over the network140can be represented using technologies and/or formats including the hypertext markup language (HTML), the extensible markup language (XML), etc. In addition, all or some links can be encrypted using conventional encryption technologies such as the secure sockets layer (SSL), Secure HTTP (HTTPS) and/or virtual private networks (VPNs). In another embodiment, the entities can use custom and/or dedicated data communications technologies instead of, or in addition to, the ones described above.

FIG. 2is a high-level block diagram illustrating physical components of a computer, such as a client110or security server120, within the enterprise105fromFIG. 1, according to one embodiment. Illustrated are at least one processor202coupled to a chipset204. Also coupled to the chipset204are a memory206, a storage device208, a keyboard210, a graphics adapter212, a pointing device214, and a network adapter216. A display218is coupled to the graphics adapter212. In one embodiment, the functionality of the chipset204is provided by a memory controller hub220and an I/O controller hub222. In another embodiment, the memory206is coupled directly to the processor202instead of the chipset204.

The storage device208is any computer-readable storage medium, such as a hard drive, compact disk read-only memory (CD-ROM), DVD, or a solid-state memory device. The memory206holds instructions and data used by the processor202. The pointing device214may be a mouse, track ball, or other type of pointing device, and is used in combination with the keyboard210to input data into the computer200. The graphics adapter212displays images and other information on the display218. The network adapter216couples the computer system200to a local or wide area network.

As is known in the art, a computer200can have different and/or other components than those shown inFIG. 2. In addition, the computer200can lack certain illustrated components. In one embodiment, a computer200acting as a server may lack a keyboard210, pointing device214, graphics adapter212, and/or display218. Moreover, the storage device208can be local and/or remote from the computer200(such as embodied within a storage area network (SAN)).

FIG. 3is a high-level block diagram illustrating a detailed view of a client110ofFIG. 1, in accordance with one embodiment. The client110is a computer, such as a personal computer, laptop computer, digital assistant, personal digital assistant, cellular phone, mobile phone, or smart phone, or more generally any device connected to the network140that may become infected by malware and on which security software can be installed. The client110comprises a malware heuristics module310for detecting an unexpected lack of access to network resources, and a distress signal sender module320for sending a distress signal message to other components within the enterprise105. The client110also comprises a beacon name information repository305for storing parameters distributed by the server120for generating a beacon name, and further for storing the beacon name once it is generated by a beacon name generation module330(described further below with respect toFIG. 5). The information repository may store only the most recently-generated beacon name, or it may store some or all of the previously-generated beacon names, along with their times of generation. Further details regarding the distributed parameters and generated beacon names are provided below with respect toFIGS. 4 and 5.

The malware heuristics module310detects a lack of access to network resources, such as communications capabilities, in situations where such access should normally be permitted. For example, a laptop that is attached to a network belonging to the enterprise105would typically have the ability to form TCP connections with other machines within that network, such as a known security server, and the absence of such ability would indicate an anomalous situation potentially caused by malware. Another example of an unexpected lack of access to network communications is the inability to access a particular predetermined network address, such as the address of a security server, while still being able to access other network addresses, which could indicate that malware is selectively blocking access to security services. Thus, the malware heuristics module310both identifies the resources to which it should have access in its current state, and further determines whether it does in fact have such access.

The distress signal sender module320sends a distress signal message, hereinafter referred to as a “beacon” or “beacon message,” destined for a distress signal receiver module. The distress signal sender module320sends the beacon to an address given by the beacon name agreed upon by the distress signal sender and the distress signal receiver, as discussed below with reference toFIG. 4. The sending of the beacon is triggered by, for example, a determination by the malware heuristics module that the client110lacks access to resources to which it is expected to have access. The beacon describes a security state of the client110, either explicitly, within the beacon message data itself, or implicitly, by receipt of the beacon. For example, in one embodiment the receipt of the beacon implicitly indicates that malware has been detected on the client110; in another embodiment, it implicitly indicates that the client continues to be malware-free. The beacon includes at least an identity of the client110, as indicated by some identifier such as an IP address, a machine name, a MAC address of a network card, an indicator of a particular physical location (e.g., stored in an RFID tag), or the like. The identity may be located in a header of a packet inclosing the beacon, or within the body of the beacon itself. The beacon may additional information in different embodiments. For example, in one embodiment the information within the beacon may include only the identity of the sending client110. In other embodiments, the beacon includes additional information such as recent network connections used by the client110, URLs recently navigated to on the client, client devices recently detected via Plug & Play, or client devices recently used by AutoRun, such information providing additional aid in identifying the exact client110that sent the beacon (and thus is presumably infected by malware), as well as potentially helping to describe how the malware behaves.

FIG. 4is a high-level block diagram illustrating a detailed view of the security server120ofFIG. 1, in accordance with one embodiment. The security server120comprises a beacon name distribution module410and—in some embodiments—a distress signal receiver420.

The beacon name distribution module410distributes, to each distress signal sender320of the clients110, and to each distress signal receiver420(which may be located on the security server120, or elsewhere), the appropriate parameters needed by the beacon name generation module540to generate the beacon names. Distribution can be done in a number of different ways in different embodiments. For example, in one embodiment each distress signal sender320and receiver420contacts the beacon name distribution module410, e.g. directly after they are installed—at which point it is expected that there has not yet been a malware infection—to obtain the parameters. The senders320and receivers420may contact the beacon name distribution module410at different times, and it will provide each with the parameters necessary to obtain synchronization, based on the time of the contact. The parameters are then stored by the clients110and the distress signal receivers420in the beacon name information repositories305,505. Redistribution of parameters need not be performed unless an error causes the senders320and receivers420to lose synchronization. In one embodiment, the parameters include an initial seed value used by the beacon name generation module540to determine the beacon name, such as URL or IP address In another embodiment, the parameters include a set of literal beacon names, along with descriptions of a time interval during which each beacon name is applicable.

The use of beacon names agreed upon by the distress signal sender320and the distress signal receiver420makes it difficult for malware to anticipate the beacon names for which to block communications, and in one embodiment this difficulty is enhanced by generating new beacon names at the expiration of set intervals. For example, each distress signal sender320and receiver420could generate a new beacon name at the end of a set period of time, e.g., a particular 20 second period. It is appreciated that the intervals need not be defined by expirations of certain time periods, but more generally can be defined based on any conditions that may be independently evaluated by the various distress signal senders320and receivers420. In some embodiments, the parameters include information in addition to the initial seed value, such as an identifier of the beacon name-generation algorithm being employed and a rule or condition for generating a new beacon name, such as a time period length (e.g., 20 seconds) after which the current beacon name expires.

The distress signal receiver420receives the beacon sent by the distress signal sender320and takes an appropriate action. The distress signal receiver420may be implemented in a number of different ways in different embodiments, and may be located on the security server120, as depicted inFIG. 4, or outside of the server, as described further below with reference toFIG. 5.

FIG. 5is a high-level block diagram illustrating in more detail the distress signal receiver420ofFIG. 4, in accordance with one embodiment. The distress signal receiver420, like the distress signal sender320ofFIG. 3, comprises a beacon name information repository505for storing parameters distributed by the server120used to generate a beacon name and for further storing the generated beacon name.

The distress signal receiver420also comprises a beacon name generation module540that uses the same algorithm as the beacon name generation module330of the client110. The beacon name generation module540generates a beacon name using the parameters provided by the beacon name distribution module410of the security server120ofFIG. 4. In an embodiment in which the parameters comprise a seed value, the beacon name distribution module540generates the beacon name according to a pseudo-random algorithm that takes the seed value as input. In an embodiment in which literal beacon names and time intervals are provided, the beacon name generation module540simply stores the provided beacon names in the beacon name information repository505in association with their respective time intervals.

The distress signal receiver420further comprises a beacon detection module510, which can be implemented in different ways in different embodiments, some of which may not be located on the security server120, as noted above. In one embodiment, the distress signal receiver420is implemented as a plug-in module to a domain name system (DNS) server that receives a DNS request from the client110as part of sending the distress signal. The DNS server may be operated by the enterprise105itself, or by an ISP or other entity external to the enterprise. In this embodiment, the beacon detection module510observes a DNS request for the IP address corresponding to the beacon name URL stored in the beacon name information repository505, an indication that the DNS request constitutes a distress signal beacon. In response to the DNS request, the beacon detection module510may additionally provide the distress signal sender320with the IP address of a security system not expected to be on a list of security servers blocked by malware, such as a security server local to the enterprise105. The distress signal sender320may then exchange messages with the security server, e.g., to provide added information about the state of the client110in order to better diagnose the malware infection. In another embodiment, the beacon detection module510need not be a module of a DNS server, but rather may be located on any machine with permission to read the DNS server's failure log. In this embodiment, the beacon detection module510periodically—e.g., every 30 seconds—scans the DNS server's failure log to identify any recent failed DNS address resolution attempts. The beacon detection module510consults the beacon name information repository505to determine the beacon name in use at the time that a particular DNS address resolution failed. If this beacon name matches the beacon name associated with the failure in the DNS log, then the beacon detection module510determines that the DNS request constituted a distress signal beacon.

In another embodiment, the beacon detection module510is located on any machine capable of monitoring network traffic, such as a router or a switch. In this embodiment, the beacon detection module510examines each packet and determines whether it is destined for an IP address stored in the beacon name information repository505as the current beacon name. If so, it then determines that the packet is a distress signal beacon.

The distress signal receiver420further comprises a sender identification module520, which determines the identity of the client110that sent the distress signal, based on the data of the beacon. Depending on the embodiment of the beacon detection module510, the client identity may be determined from standard header information, e.g. the source IP address of a packet enclosing a DNS request, or the source IP address of a packet destined for a beacon IP address, or from DNS failure logs. Alternatively, in embodiments in which the beacon includes a client identifier, such as an IP address, MAC address, or machine name, in the body of the message, the sender identification module520can instead rely on this identifier. The distress signal receiver420further comprises a remediation module530, which takes a remedial action in response to detection of a beacon by the beacon detection module510. The action taken is different in different embodiments. For example, in one embodiment the remediation module530creates an entry in a local log, the entry including information such as the identity of the client110sending the beacon, the time of receipt of the beacon, and the like. In another embodiment, the remediation module sends a notification of the beacon to a management console process executing on the server120or on another system accessible to enterprise administrators. The management console then displays information on the beacon, such as the identity of the client and time of beacon receipt, e.g. within a graphical user interface or in a command shell. Administrators can then investigate the problem and take manual steps to remedy it. Alternatively, the server120may attempt to automatically remove the malware, such as by attempting to remotely execute a malware removal program. In still another embodiment, the remediation module530sends alert emails, e.g. to the client110or to administrators of the enterprise, that note that the client110may be infected with malware. Other embodiments may employ any combination of these remedial actions.

FIG. 6depicts interactions that take place as part of beacon sending and detection, in accordance with one embodiment. Preliminarily, the beacon name distribution module410distributes the parameters—such as a seed value—for generating the beacon name to the distress signal senders320and receivers420, as discussed above. The senders320and receivers420then store the parameters in their beacon name information repositories305,505and generate310a first beacon name based on the parameters, which they then store in the information repositories. In one embodiment, the senders320and receivers420continue to generate new beacon names at given times in synchronization with each other; for example, in one embodiment they all generate new beacon names at the expiration of a given period of time, where the period of time can be made consistent by each sender and receiver synchronizing its system clock with a common timekeeper.

At some subsequent time, the malware heuristics module310of a client110ofFIG. 1detects620an unexpected failure to access a network resource, the failure indicating the possible presence of malware on the client110. In response, the distress signal sender320constructs a beacon message including an identity of the client110, such as an IP address, a machine name, or a MAC address. In one embodiment in which the beacon name includes a hostname (e.g., the hostname itself, or a URL containing it), the beacon message is a DNS request attempting to resolve the hostname and is addressed to a DNS server. In another embodiment in which the beacon name is an IP address, the beacon message is addressed directly to the IP address.

The distress signal receiver420detects645the beacon via the beacon detection module510. As discussed above, the beacon detection module510can be implemented in different manners in different embodiments, such as a network traffic monitor on a network device, a DNS server plug-in, or a DNS log reader located on the DNS server or on any machine with permission to read the DNS server log. The distress signal receiver420then identifies650the sender by examining information in the beacon packet headers or in the body of the beacon message, and performs655an appropriate remedial action to address the possible existence of malware indicated by the beacon, such as logging the beacon message, sending alert messages such as emails to the client110or the server120, or the like.

In some embodiments, the distress signal receiver420obtains information in addition to the identity of the sender. For example, in an embodiment in which the distress signal sender320places additional information, such as a list of URLs recently navigated, in the body of the beacon message, and the distress signal receiver420receives the entire beacon message directly, it may simply examine the body of the beacon message to obtain the additional information. For example, the distress signal receiver420receives the beacon message directly in embodiments in which it executes as a plug-in to a router or DNS server. In contrast, in embodiments in which the distress signal receiver420executes as, for example, a DNS failure log reader, the beacon packet is discarded by the DNS server prior to creation of a log entry, and so the distress signal receiver can only obtain the sender address from the DNS log.

As one alternative embodiment of special applicability in situations where the malware blocks all communications of the client110, and not merely communications to well-known security servers120, the absence of a beacon message from a client110is determined by the distress signal receiver420to indicate the presence of malware on the client110. More specifically, the parameters are distributed605and beacon names generated610as above. Then, while the client110has access to communications, its distress signal sender module320sends a “heartbeat” beacon at regular intervals to the beacon name. The distress signal receiver420then detects645the beacon and identifies650the client110that sent it, noting that the client still has access to network communications. However, if the client110becomes infected with communications-blocking malware, then the heartbeat beacons from the client will be blocked and the distress signal receiver420will consequently not receive a beacon during the expected time interval. Thus, the distress signal receiver420will perform655a remedial action with respect to the client110. Note that the fact that the beacon names are employed in this embodiment makes it difficult for malware to send its own simulated heartbeat beacons in order to prevent the infection from being discovered, since the malware will not know the current beacon name expected by the distress signal receiver420.