System and method for detecting malicious traffic using a virtual machine configured with a select software environment

Information

  • Patent Grant
  • 11637857
  • Patent Number
    11,637,857
  • Date Filed
    Friday, February 14, 2020
    6 years ago
  • Date Issued
    Tuesday, April 25, 2023
    3 years ago
Abstract
A system for detecting malware is described. The system features a traffic analysis device and a network device. The traffic analysis device is configured to receive data over a communication network, selectively filter the data, and output a first portion of the data to the network device. The network device is communicatively coupled with and remotely located from the traffic analysis device. The network device features software that, upon execution, (i) monitors behaviors of one or more virtual machines processing the first portion of the data received as output from the traffic analysis device, and (ii) detects, based on the monitored behaviors, a presence of malware in the first virtual machine.
Description
FIELD

The present invention relates generally to computing systems, and more particularly to systems and methods of detecting computer worms in computer networks.


GENERAL BACKGROUND

Detecting and distinguishing computer worms from ordinary communications traffic within a computer network is a challenging problem. Moreover, modern computer worms operate at an ever increasing level of sophistication and complexity. Consequently, it has become increasingly difficult to detect computer worms.


A computer worm can propagate through a computer network by using active propagation techniques. One active propagation technique of a computer worm is to select target systems to infect by scanning a network address space of a computer network (e.g., a scan directed computer worm). Another active propagation technique of a computer worm is to use topological information from an infected system in a computer network to actively propagate the computer worm in the computer network (e.g., a topologically directed computer worm). Still another active propagation technique of a computer worm is to select target systems to infect based on a previously generated list of target systems (e.g., a hit-list directed computer worm).


In addition to active propagation techniques, a computer worm may propagate through a computer network by using passive propagation techniques. One passive propagation technique of a computer worm is to attach itself to normal network communications not initiated by the computer worm itself (e.g., a stealthy or passive contagion computer worm). The computer worm then propagates through the computer network in the context of normal communication patterns not directed by the computer worm.


It is anticipated that next-generation computer worms will have multiple transport vectors, use multiple target selection techniques, have no previously known signatures, and will target previously unknown vulnerabilities. It is also anticipated that next generation computer worms will use a combination of active and passive propagation techniques and may emit chaff traffic (i.e., spurious traffic generated by the computer worm) to cloak the communication traffic that carries the actual exploit sequences of the computer worms. This chaff traffic will be emitted in order to confuse computer worm detection systems and to potentially trigger a broad denial-of-service by an automated response system.


Approaches for detecting computer worms in a computer system include misuse detection and anomaly detection. In misuse detection, known attack patterns of computer worms are used to detect the presence of the computer worm. Misuse detection works reliably for known attack patterns but is not particularly useful for detecting novel attacks. In contrast to misuse detection, anomaly detection has the ability to detect novel attacks. In anomaly detection, a baseline of normal behavior in a computer network is created so that deviations from this behavior can be flagged as an anomaly. The difficulty inherent in this approach is that universal definitions of normal behavior are difficult to obtain. Given this limitation, anomaly detection approaches strive to minimize false positive rates of computer worm detection.


In one suggested computer worm containment system, detection devices are deployed in a computer network to monitor outbound network traffic and detect active scan directed computer worms in the computer network. To achieve effective containment of these active computer worms (as measured by the total infection rate over the entire population of systems), the detection devices are widely deployed in the computer network in an attempt to detect computer worm traffic close to a source of the computer worm traffic. Once detected, these computer worms are contained by using an address blacklisting technique. This computer worm containment system, however, does not have a mechanism for repair and recovery of infected computer networks.


In another suggested computer worm containment system, the protocols (e.g., network protocols) of network packets are checked for standards compliance under an assumption that a computer worm will violate the protocol standards (e.g., exploit the protocol standards) in order to successfully infect a computer network. While this approach may be successful in some circumstances, this approach is limited in other circumstances. Firstly, it is possible for a network packet to be fully compatible with published protocol standard specifications and still trigger a buffer overflow type of software error due to the presence of a software bug. Secondly, not all protocols of interest can be checked for standards compliance because proprietary or undocumented protocols may be used in a computer network. Moreover, evolutions of existing protocols and the introduction of new protocols may lead to high false positive rates of computer worm detection when “good” behavior cannot be properly and completely distinguished from “bad” behavior. Encrypted communications channels further complicate protocol checking because protocol compliance cannot be easily validated at the network level for encrypted traffic.


In another approach to computer worm containment, “honey farms” have been proposed. A honey farm includes “honeypots” that are sensitive to probe attempts in a computer network. One problem with this approach is that probe attempts do not necessarily indicate the presence of a computer worm because there may be legitimate reasons for probing a computer network. For example, a computer network can be legitimately probed by scanning an Internet Protocol (IP) address range to identify poorly configured or rogue devices in the computer network. Another problem with this approach is that a conventional honey farm does not detect passive computer worms and does not extract signatures or transport vectors in the face of chaff emitting computer worms.


Another approach to computer worm containment assumes that computer worm probes are identifiable at a given worm sensor in a computer network because the computer worm probes will target well known vulnerabilities and thus have well known signatures which can be detected using a signature-based intrusion detection system. Although this approach may work for well known computer worms that periodically recur, such as the CodeRed computer worm, this approach does not work for novel computer worm attacks exploiting a zero-day vulnerability (e.g., a vulnerability that is not widely known).


One suggested computer worm containment system attempts to detect computer worms by observing communication patterns between computer systems in a computer network. In this system, connection histories between computer systems are analyzed to discover patterns that may represent a propagation trail of the computer worm. In addition to false positive related problems, the computer worm containment system does not distinguish between the actual transport vector of a computer worm and a transport vector including a spuriously emitted chaff trail. As a result, simply examining malicious traffic to determine the transport vector can lead to a broad denial of service (DOS) attack on the computer network. Further, the computer worm containment system does not determine a signature of the computer worm that can be used to implement content filtering of the computer worm. In addition, the computer worm containment system does not have the ability to detect stealthy passive computer worms, which by their very nature cause no anomalous communication patterns.


In light of the above, there exists a need for an effective system and method of detecting computer worms.


SUMMARY

A computer worm detection system addresses the need for detecting computer worms. In accordance with various embodiments, a computer worm sensor is coupled to a communication network. The computer worm sensor allows a computer worm to propagate from the communication network to a computer network in the computer worm sensor. The computer worm sensor orchestrates network activities in the computer network, monitors the behavior of the computer network, and identifies an anomalous behavior in the monitored behavior to detect a computer worm. Additionally, the computer worm detection system determines an identifier for detecting the computer worm based on the anomalous behavior.


A system in accordance with one embodiment includes a computer network and a controller in communication with the computer network. The controller is configured to orchestrate a predetermined sequence of network activities in the computer network, monitor a behavior of the computer network in response to the predetermined sequence of network activities, and identify an anomalous behavior in the monitored behavior to detect the computer worm.


A method in accordance with one embodiment includes orchestrating a predetermined sequence of network activities in a computer network and monitoring a behavior of the computer network in response to the predetermined sequence of network activities. Further, the method comprises identifying an anomalous behavior in the monitored behavior to detect the computer worm.





BRIEF DESCRIPTION OF THE DRAWINGS


FIG. 1 depicts a computing environment in which a worm sensor can be implemented, in accordance with one embodiment of the present invention;



FIG. 2 depicts a controller of a computer worm sensor, in accordance with one embodiment of the present invention;



FIG. 3 depicts a computer worm detection system, in accordance with one embodiment of the present invention; and



FIG. 4 depicts a flow chart for a method of detecting computer worms, in accordance with one embodiment of the present invention.





DETAILED DESCRIPTION

A computer worm detection system in accordance with one embodiment of the present invention orchestrates network activities in a computer network and monitors the behavior of the computer network. The computer worm detection system detects a computer worm in the computer network based on the monitored behavior of the computer network. Additionally, the computer worm detection system determines an identifier, such as a signature or a vector, for detecting the computer worm. The computer worm detection system can generate a recovery script to disable the computer worm and repair damage caused by the computer worm.



FIG. 1 depicts an exemplary computing environment 100 in which a computer worm sensor 105 can be implemented, in accordance with one embodiment of the present invention. In various embodiments, the computer worm sensor 105 functions as a computer worm detection system, as is described more fully herein. The computer worm sensor 105 includes a controller 115, a computer network 110 (e.g., a hidden network), and a gateway 125 (e.g., a wormhole system). The computer network 110 includes one or more computing systems 120 (e.g., hidden systems) in communication with each other. The controller 115 and the gateway 125 are in communication with the computer network 110 and the computing systems 120. Additionally, the gateway 125 is communication with a communication network 130 (e.g., a production network). The communication network 130 can be a public computer network (e.g., the Internet) or a private computer network (e.g., a wireless telecommunication network).


Optionally, the computer worm sensor 105 may include one or more traffic analysis devices 135 in communication with the communication network 130. The traffic analysis device 135 analyzes network traffic in the communication network 130 to identify network communications characteristic of a computer worm. The traffic analysis device 135 can then selectively duplicate the identified network communications and provide the duplicated network communications to the controller 115. The controller 115 replays the duplicated network communications in the computer network 110 to determine whether the network communications include a computer worm.


The computing systems 120 are computing devices typically found in a computer network. For example, the computing systems 120 can include computing clients or servers. As a further example, the computing systems 120 can include gateways and subnets in the computer network 110. Each of the computing systems 120 and the gateway 125 may have different hardware or software profiles.


The gateway 125 allows computer worms to pass from the communication network 130 to the computer network 110. The computer worm sensor 105 may include multiple gateways 125 in communication with multiple communication networks 130. These communication networks 130 may also be in communication with each other. For example, the communication networks 130 can be part of the Internet or in communication with the Internet. In one embodiment, each of the gateways 125 can be in communication with multiple communication networks 130.


The controller 115 controls operation of the computing systems 120 and the gateway 125 to orchestrate network activities in the computer worm sensor 105. In one embodiment, the orchestrated network activities are a predetermined sequence of network activities in the computer network 110, which represents an orchestrated behavior of the computer network 110. In this embodiment, the controller 115 monitors the computer network 110 to determine a monitored behavior of the computer network 110 in response to the orchestrated network activities. The controller 115 then compares the monitored behavior of the computer network 110 with the predetermined orchestrated behavior to identify an anomalous behavior. The anomalous behavior may include a communication anomaly (e.g., an unexpected network communication) or an execution anomaly (e.g., an unexpected execution of computer program code) in the computer network 110. If the controller 115 identifies an anomalous behavior, the computer network 110 is deemed infected with a computer worm. In this way, the controller 115 can detect the presence of a computer worm in the computer network 110 based on an anomalous behavior of the computer worm in the computer network 110. The controller 115 then creates an identifier (i.e., a “definition” of the anomalous behavior), which may be used for detecting the computer worm in another computer network (e.g., the communication network 130).


The identifier determined by the controller 115 for a computer worm in the computer network 110 may be a signature that characterizes an anomalous behavior of the computer worm. The signature can then be used to detect the computer worm in another computer network (e.g., the communication network 130). In one embodiment, the signature indicates a sequence of ports in the computer network 110 along with data used to exploit each of the ports. The signature may be a set of tuples {(p1, c1) (p2, c2), . . . }, where pn, represents a Transfer Control Protocol (TCP) or a User Datagram Protocol (UDP) port number, and cn is signature data contained in a TCP or UDP packet used to exploit a port associated with the port number. For example, the signature data can be 16-32 bytes of data in a data portion of a data packet.


The controller 115 can determine a signature of a computer worm based on a uniform resource locator (URL), and can generate the signature by using a URL filtering device, which represents a specific case of content filtering. For example, the controller 115 can identify a uniform resource locator (URL) in data packets of Hyper Text Transfer Protocol (HTTP) traffic and can extract a signature from the URL. Further, the controller 115 can create a regular expression for the URL and include the regular expression in the signature. In this way, a URL filtering device can use the signature to filter out network traffic associated with the URL.


Alternatively, the identifier may be a vector (e.g., a propagation vector, an attack vector, or a payload vector) that characterizes an anomalous behavior of the computer worm in the computer network 110. For example, the vector can be a propagation vector (i.e., a transport vector) that characterizes a sequence of paths traveled by the computer worm in the computer network 110. The propagation vector may include a set {p1, p2, p3, . . . }, where pn represents a port number (e.g., a TCP or UDP port number) in the computer network 110 and identifies a transport protocol (e.g., TCP or UDP) used by the computer worm to access the port. Further, the identifier may be a multi-vector that characterizes multiple propagation vectors for the computer worm. In this way, the vector can characterize a computer worm that uses a variety of techniques to propagate in the computer network 110. These techniques may include dynamic assignment of probe addresses to the computing systems 120, network address translation (NAT) of probe addresses to the computing systems 120, obtaining topological service information from the computer network 110, or propagating through multiple gateways 125 of the computer worm sensor 105.


The controller 115 may orchestrate network activities (e.g., network communications or computing services) in the computer network 110 based on one or more orchestration patterns. In one embodiment, the controller 115 generates a series of network communications based on an orchestration pattern to exercise one or more computing services (e.g., Telnet, FTP, or SMTP) in the computer network 110. In this embodiment, the orchestration pattern defines an orchestrated behavior (e.g., an expected behavior) of the computer network 110. The controller 115 then monitors network activities in the computer network 110 (e.g., the network communications and computing services accessed by the network communications) to determine the monitored behavior of the computer network 110, and compares the monitored behavior with the orchestration pattern. If the monitored behavior does not match the orchestration pattern, the computer network 110 is deemed infected with a computer worm. The controller 115 then identifies an anomalous behavior in the monitored behavior (e.g., a network activity in the monitored behavior that does not match the orchestration pattern) and determines an identifier for the computer worm based on the anomalous behavior.


In another embodiment, an orchestrated pattern is associated with a type of network communication. In this embodiment, the gateway 125 identifies the type of a network communication received by the gateway 125 from the communication network 130 before propagating the network communication to the computer network 110. The controller 115 then selects an orchestration pattern based on the type of network communication identified by the gateway 125 and orchestrates network activities in the computer network 110 based on the selected orchestration pattern. In the computer network 110, the network communication accesses one or more computing systems 120 via one or more ports to access one or more computing services (e.g., network services) provided by the computing systems 120. For example, the network communication may access an FTP server on one of the computing systems 120 via a well-known or registered FTP port number using an appropriate network protocol (e.g., TCP or UDP). In this example, the orchestration pattern includes the identity of the computing system 120, the FTP port number, and the appropriate network protocol for the FTP server. If the monitored behavior of the computer network 110 does not match the orchestrated behavior defined by the orchestration pattern, the network communication is deemed infected with a computer worm. The controller 115 then determines an identifier for the computer worm based on the monitored behavior, as is described in more detail herein.


The controller 115 orchestrates network activities in the computer network 110 such that detection of anomalous behavior in the computer network 110 is simple and highly reliable. All behavior (e.g., network activities) of the computer network 110 that is not part of an orchestration pattern represents an anomalous behavior. In alternative embodiments, the monitored behavior of the computer network 110 that is not part of the orchestration pattern is analyzed to determine whether any of the monitored behavior is an anomalous behavior.


In another embodiment, the controller 115 periodically orchestrates network activities in the computer network 110 to access various computing services (e.g., web servers or file servers) in the communication network 130. In this way, a computer worm that has infected one of these computing services may propagate from the communication network 130 to the computer network 110 via the orchestrated network activities. The controller 115 then orchestrates network activities to access the same computing services in the computer network 110 and monitors a behavior of the computer network 110 in response to the orchestrated network activities. If the computer worm has infected the computer network 110, the controller 115 detects the computer worm based on an anomalous behavior of the computer worm in the monitored behavior, as is described more fully herein.


In one embodiment, a single orchestration pattern exercises all available computing services in the computer network 110. In other embodiments, each orchestration pattern exercises selected computing services in the computer network 110, or the orchestration patterns for the computer network 110 are dynamic (e.g., vary over time). For example, a user of the computer worm sensor 105 may add, delete, or modify the orchestration patterns to change the orchestrated behavior of the computer network 110.


In one embodiment, the controller 115 orchestrates network activities in the computer network 110 to prevent a computer worm in the communication network 130 from detecting the computer network 110. For example, a computer worm may identify and avoid inactive computer networks, which may be decoy computer networks deployed for detecting the computer worm (e.g., the computer network 110). In this embodiment, the controller 115 orchestrates network activities in the computer network 110 to prevent the computer worm from avoiding the computer network 110 because of inactivity in the computer network 110.


In another embodiment, the controller 115 analyzes both the packet header and the data portion of data packets in network communications in the computer network 110 to detect anomalous behavior in the computer network 110. For example, the controller 115 can compare the packet header and the data portion of the data packets with an orchestration pattern to determine whether the data packets constitute anomalous behavior in the computer network 110. Because the network communication containing the data packets is an orchestrated behavior of the computer network 110, the controller 115 avoids false positive detection of anomalous behavior in the computer network 110, which may occur in anomaly detection systems operating on unconstrained computer networks. In this way, the controller 115 reliably detects computer worms in the computer network 110 based on the anomalous behavior.


To illustrate what is meant by reliable detection of anomalous behavior, for example, an orchestration pattern may be used that is expected to cause emission of a sequence of data packets (a, b, c, d) in the computer network 110. The controller 115 orchestrates network activities in the computer network 110 based on the orchestration pattern and monitors the behavior (e.g., measures the network traffic) of the computer network 110. If the monitored behavior (e.g., the measured network traffic) of the computer network 110 includes a sequence of data packets (a, b, c, d, e, f), the data packets (e, f) represent an anomalous behavior (e.g., anomalous traffic) in the computer network 110. This anomalous behavior may be caused by an active computer worm propagating inside the computer network 110.


As another example, if an orchestration pattern is expected to cause emission of a sequence of data packets (a, b, c, d) in the computer network 110, but the monitored behavior includes a sequence of data packets (a, b′, c′, d), the data packets (b′, c′) represents an anomalous behavior in the computer network 110. This anomalous behavior may be caused by a passive computer worm propagating inside the computer network 110.


In various further embodiments, the controller 115 generates a recovery script for the computer worm, as is described more fully herein. The controller 115 can then execute the recovery script to disable (e.g., destroy) the computer worm in the computer worm sensor 105 (e.g., remove the computer worm from the computing systems 120 and the gateway 125). Moreover, the controller 115 can output the recovery script for use in disabling the computer worm in other infected computer networks and systems.


In another embodiment, the controller 115 identifies the source of a computer worm based on a network communication containing the computer worm. For example, the controller 115 may identify an infected host (e.g., a computing system) in the communication network 130 that generated the network communication containing the computer worm. In this example, the controller 115 transmits the recovery script via the gateway 125 to the host in the communication network 130. In turn, the host executes the recovery script to disable the computer worm in the host. In various further embodiments, the recovery script is also capable of repairing damage to the host caused by the computer worm.


The computer worm sensor 105 may store the recovery script in a bootable compact disc (CD) or floppy that can be loaded into infected hosts (e.g., computing systems) to repair the infected hosts. For example, the recovery script can include an operating system for the infected host and repair scripts that are invoked as part of the booting process of the operating system to repair an infected host. Alternatively, the computer worm sensor 130 may provide the recovery script to an infected computer network (e.g., the communication network 130) so that the computer network 130 can direct infected hosts in the communication network 130 to reboot and load the operating system in the recovery script.


In another embodiment, the computer worm sensor 105 uses a per-host detection and recovery mechanism to recover hosts (e.g., computing systems) in a computer network (e.g., the communication network 130). The computer worm sensor 105 generates a recovery script including a detection process for detecting the computer worm and a recovery process for disabling the computer worm and repairing damage caused by the computer worm. The computer worm sensor 105 provides the recovery script to hosts in a computer network (e.g., the communication network 130) and each host executes the detection process. If the host detects the computer worm, the host then executes the recovery process. In this way, a computer worm that performs random corruptive acts on the different hosts (e.g., computing systems) in the computer network can be disabled in the computer network and damage to the computer network caused by the computer worm can be repaired.


The computer worm sensor 105 may be a single integrated system, such as a network device or a network appliance, which is deployed in the communication network 130 (e.g., commercial or military computer network). Alternatively, the computer worm sensor 105 may include integrated software for controlling operation of the computer worm sensor 105, such that per-host software (e.g., individual software for each computing system 120 and gateway 125) is not required.


The computer worm sensor 105 may be a hardware module, such as a combinational logic circuit, a sequential logic circuit, a programmable logic device, or a computing device, among others. Alternatively, the computer worm sensor 105 may include one or more software modules containing computer program code, such as a computer program, a software routine, binary code, or firmware, among others. The software code may be contained in a permanent memory storage device such as a compact disc read-only memory (CD-ROM), a hard disk, or other memory storage device. In various embodiment, the computer worm sensor 105 includes both hardware and software modules.


In various embodiments, the computer worm sensor 105 is substantially transparent to the communication network 130 and does not substantially affect the performance or availability of the communication network 130. For example, the software in the computer worm sensor 105 may be hidden such that a computer worm cannot detect the computer worm sensor 105 by checking for the existence of files (e.g., software programs) in the computer worm sensor 105 or by performing a simple signature check of the files. In other embodiments, the software configuration of the computer worm sensor 105 is hidden by employing one or more well-known polymorphic techniques used by viruses to evade signature based detection.


In another embodiment, the gateway 125 facilitates propagation of computer worms from the communication network 130 to the computer network 110, with the controller 115 orchestrating network activities in the computer network 110 to actively propagate a computer worm from the communication network 130 to the computer network 110. For example, the controller 115 can originate one or more network communications between the computer network 110 and the communication network 130. In this way, a passive computer worm in the communication network 130 can attach to one of the network communications and propagate along with the network communication from the communication network 130 to the computer network 110. Once the computer worm is in the computer network 110, the controller 115 can detect the computer worm based on an anomalous behavior of the computer worm, as is described in more fully herein.


In another embodiment, the gateway 125 selectively prevents normal network traffic (e.g., network traffic not generated by a computer worm) from propagating from the communication network 130 to the computer network 110 to prevent various anomalies or perturbations in the computer network 110. In this way, the orchestrated behavior of the computer network 110 may be simplified and the reliability of computer worm sensor 105 may be increased. For example, the gateway 125 can prevent Internet Protocol (IP) data packets from being routed from the communication network 130 to the computer network 110. Alternatively, the gateway 125 can prevent broadcast and multicast network communications from being transmitted from the communication network 130 to the computer network 110, prevent communications generated by remote shell applications (e.g., Telnet) in the communication network 130 from propagating to the computer network 110, or exclude various application level gateways including proxy services that are typically present in a computer network for application programs in the computer network. Such application programs may include a Web browser, an FTP server and a mail server, and the proxy services may include the Hypertext Markup Language (HTML), the File Transfer Protocol (FTP), or the Simple Mail Transfer Protocol (SMTP)).


In another embodiment, the computing systems 120 and the gateway 125 are virtual computing systems. For example, the computing systems 120 may be implemented as virtual systems using machine virtualization technologies such as VMware™ sold by VMware, Inc. In another embodiment, the virtual systems include VM software profiles and the controller 115 automatically updates the VM software profiles to be representative of the communication network 130. The gateway 125 and the computer network 110 may also be implemented as a combination of virtual systems and real systems.


In another embodiment, the computer network 110 is a virtual computer network. The computer network 110 includes network device drivers (e.g., special purpose network device drivers) that do not access a physical network, but instead use software message passing between the different virtual computing systems 120 in the computer network 110. The network device drivers may log data packets of network communications in the computer network 110, which represent the monitored behavior of the computer network 110.


In various embodiments, the computer worm sensor 105 establishes a software environment of the computer network 110 (e.g., computer programs in the computing systems 120) to reflect a software environment of a selected computer network (e.g., the communication network 130). For example, the computer worm sensor 105 can select a software environment of a computer network typically attacked by computer worms (e.g., a software environment of a commercial communication network) and can configure the computer network 110 to reflect that software environment. In a further embodiment, the computer worm sensor 105 updates the software environment of the computer network 110 to reflect changes in the software environment of the selected computer network. In this way, the computer worm sensor 105 can effectively detect a computer worm that targets a recently deployed software program or software profile in the software environment (e.g., a widely deployed software profile).


The computer worm sensor 105 may also monitor the software environment of the selected computer network and automatically update the software environment of the computer network 110 to reflect the software environment of the selected computer network. For example, the computer worm sensor 105 can modify the software environment of the computer network 110 in response to receiving an update for a software program (e.g., a widely used software program) in the software environment of the selected computer network.


In another embodiment, the computer worm sensor 105 has a probe mechanism to automatically check the version, the release number, and the patch-level of major operating systems and application software components installed in the communication network 130. Additionally, the computer worm sensor 110 has access to a central repository of up-to-date versions of the system and application software components. In this embodiment, the computer worm sensor 110 detects a widely used software component (e.g., software program) operating in the communication network 130, downloads the software component from the central repository, and automatically deploys the software component in the computer network 110 (e.g., installs the software component in the computing systems 120). The computer worm sensor 105 may coordinate with other computer worm sensors 105 to deploy the software component in the computer networks 110 of the computer worm sensors 105. In this way, each software environment of the computer worm sensors 105 is modified to contain the software component.


In another embodiment, the computer worm sensors 105 are automatically updated from a central computing system (e.g., a computing server) by using a push model. In this embodiment, the central computing system obtains updated software components and sends the updated software components to the computer worm sensors 105. Moreover, the software environments of the computer worm sensors 105 can represent widely deployed software that computer worms are likely to target. Examples of available commercial technologies that can aid in the automated update of software and software patches in a networked environment include N1 products sold by SUN Microsystems, Inc™ and Adaptive Infrastructure products sold by the Hewlett Packard Company™.


The computer worm sensor 105 may maintain an original image of the computer network 110 (e.g., a copy of the original file system for each computing system 120) in a virtual machine that is isolated from the computer network 110 and the communication network 130 (e.g., not connected to the computer network 110 or the communication network 130). The computer worm sensor 105 obtains a current image of an infected computing system 120 (e.g., a copy of the current file system of the computing system 120) and compares the current image with the original image of the computer network 110 to identify any discrepancies between these images, which represent an anomalous behavior of a computer worm in the infected computing system 120.


The computer worm sensor 105 generates a recovery script based on the discrepancies between the current image and the original image of the computing system 120, which may be used for disabling the computer worm in the infected computing system 120 and repairing damage to the infected computing system 120 caused by the computer worm. For example, the recovery script may include computer program code for identifying infected software programs or memory locations based on the discrepancies, and removing the discrepancies from the infected software programs or memory locations. The infected computing system 120 can then execute the recovery script to disable (e.g., destroy) the computer worm and repair any damage to the infected computing system 120 caused by the computer worm.


The recovery script may include computer program code for replacing the current file system of the computing system 120 with the original file system of the computing system 120 in the original image of the computer network 110. Alternatively, the recovery script may include computer program code for replacing infected files with the corresponding original files of the computing system 120 in the original image of the computer network 110. In still another embodiment, the computer worm sensor 105 includes a file integrity checking mechanism (e.g., a tripwire) for identifying infected files in the current file system of the computing system 120. The recovery script may also include computer program code for identifying and restoring files modified by a computer worm to reactivate the computer worm during reboot of the computing system 120 (e.g., reactivate the computer worm after the computer worm is disabled).


In one embodiment, the computer worm sensor 105 occupies a predetermined address space (e.g., an unused address space) in the communication network 130. The communication network 130 redirects those network communications directed to the predetermined address space to the computer worm sensor 105. For example, the communication network 130 can redirect network communications to the computer worm sensor 105 by using various IP layer redirection techniques. In this way, an active computer worm using a random IP address scanning technique (e.g., a scan directed computer worm) can randomly select an address in the predetermined address space and can infect the computer worm sensor 105 based on the selected address (e.g., transmitting a network communication containing the computer worm to the selected address).


An active computer worm can select an address in the predetermined address space based on a previously generated list of target addresses (e.g., a hit-list directed computer worm) and can infect a computing system 120 located at the selected address. Alternatively, an active computer worm can identify a target computing system 120 located at the selected address in the predetermined address space based on a previously generated list of target systems, and then infect the target computing system 120 based on the selected address.


In various embodiments, the computer worm sensor 105 identifies data packets directed to the predetermined address space and redirects the data packets to the computer worm sensor 105 by performing network address translation (NAT) on the data packets. For example, the computer network 110 may perform dynamic NAT on the data packets based on one or more NAT tables to redirect data packets to one or more computing systems 120 in the computer network 110. In the case of a hit-list directed computer worm having a hit-list that does not have a network address of a computing system 120 in the computer network 110, the computer network 110 can perform NAT to redirect the hit-list directed computer worm to one of the computing systems 120. Further, if the computer worm sensor 105 initiates a network communication that is not defined by the orchestrated behavior of the computer network 110, the computer network 110 can dynamically redirect the data packets of the network communication to a computing system 120 in the computer network 110.


In another embodiment, the computer worm sensor 105 operates in conjunction with dynamic host configuration protocol (DHCP) servers in the communication network 130 to occupy an address space in the communication network 130. In this embodiment, the computer worm sensor 105 communicates with each DHCP server to determine which IP addresses are unassigned to a particular subnet associated with the DHCP server in the communication network 130. The computer worm sensor 105 then dynamically responds to network communications directed to those unassigned IP addresses. For example, the computer worm sensor 105 can dynamically generate an address resolution protocol (ARP) response to an ARP request.


In another embodiment, the traffic analysis device 135 analyzes communication traffic in the communication network 130 to identify a sequence of network communications characteristic of a computer worm. The traffic analysis device 135 may use one or more well-known worm traffic analysis techniques to identify a sequence of network communications in the communication network 130 characteristic of a computer worm. For example, the traffic analysis device 135 may identify a repeating pattern of network communications based on the destination ports of data packets in the communication network 130. The traffic analysis device 135 duplicates one or more network communications in the sequence of network communications and provides the duplicated network communications to the controller 115, which emulates the duplicated network communications in the computer network 110.


The traffic analysis device 135 may identify a sequence of network communications in the communication network 130 characteristic of a computer worm by using heuristic analysis techniques (i.e., heuristics) known to those skilled in the art. For example, the traffic analysis device 135 may detect a number of IP address scans, or a number of network communications to an invalid IP address, occurring within a predetermined period. The traffic analysis device 135 determines whether the sequence of network communications is characteristic of a computer worm by comparing the number of IP address scans or the number of network communications in the sequence to a heuristics threshold (e.g., one thousand IP address scans per second).


The traffic analysis device 135 may lower typical heuristics thresholds of these heuristic techniques to increase the rate of computer worm detection, which may also increase the rate of false positive computer worm detection by the traffic analysis device 135. Because the computer worm sensor 105 emulates the duplicated network communications in the computer network 110 to determine whether the network communications include an anomalous behavior of a computer worm, the computer worm sensor 105 may increase the rate of computer worm detection without increasing the rate of false positive worm detection.


In another embodiment, the traffic analysis device 135 filters network communications characteristic of a computer worm in the communication network 130 before providing duplicating network communications to the controller 115. For example, a host A in the communication network 130 can send a network communication including an unusual data byte sequence (e.g., worm code) to a TCP/UDP port of a host B in the communication network 130. In turn, the host B can send a network communication including a similar unusual data byte sequence to the same TCP/UDP port of a host C in the communication network 130. In this example, the network communications from host A to host B and from host B to host C represent a repeating pattern of network communication. The unusual data byte sequences may be identical data byte sequences or highly correlated data byte sequences. The traffic analysis device 135 filters the repeating pattern of network communications by using a correlation threshold to determine whether to duplicate the network communication and provide the duplicated network communication to the controller 115.


The traffic analysis device 135 may analyze communication traffic in the communication network 130 for a predetermined period. For example, the predetermined period can be a number of seconds, minutes, hours, or days. In this way, the traffic analysis device 135 can detect slow propagating computer worms as well as fast propagating computer worms in the communication network 130.


The computer worm sensor 105 may contain a computer worm (e.g., a scanning computer worm) within the computer network 110 by performing dynamic NAT on an unexpected network communication originating in the computer network 110 (e.g., an unexpected communication generated by a computing system 120). For example, the computer worm sensor 105 can perform dynamic NAT on data packets of an IP address range scan originating in the computer network 110 to redirect the data packets to a computing system 120 in the computer network 110. In this way, the network communication is contained in the computer network 110.


In another embodiment, the computer worm sensor 105 is topologically knit into the communication network 130 to facilitate detection of a topologically directed computer worm. The controller 115 may use various network services in the communication network 130 to topologically knit the computer worm sensor 105 into the communication network 130. For example, the controller 115 may generate a gratuitous ARP response including the IP address of a computing system 120 to the communication network 130 such that a host in the communication network 130 stores the IP address in an ARP cache. In this way, the controller 115 plants the IP address of the computing system 120 into the communication network 130 to topologically knit the computing system 120 into the communication network 130.


The ARP response generated by the computer worm sensor 105 may include a media access control (MAC) address and a corresponding IP address for one or more of the computing systems 120. A host (e.g., a computing system) in the communication network 130 can then store the MAC and IP addresses in one or more local ARP caches. A topologically directed computer worm can then access the MAC and IP addresses in the ARP caches and can target the computing systems 120 based on the MAC or IP addresses.


In various embodiments, the computer worm sensor 105 can accelerate network activities in the computer network 110. In this way, the computer worm sensor 105 can reduce the time for detecting a time-delayed computer worm (e.g., the CodeRed-II computer worm) in the computer network 110. Further, accelerating the network activities in the computer network 110 may allow the computer worm sensor 105 to detect the time-delayed computer worm before the time-delayed computer worm causes damage in the communication network 130. The computer worm sensor 105 can then generate a recovery script for the computer worm and provide the recovery script to the communication network 130 for disabling the computer worm in the communication network 130.


The computing system 120 in the computer network may accelerate network activities by intercepting time-sensitive system calls (e.g., “time-of-day” or “sleep” system calls) generated by a software program executing in the computing system 120 or responses to such systems calls, and modifying the systems calls or responses to accelerate execution of the software program. For example, the computing system 120 can modify a parameter of a “sleep” system call to reduce the execution time of this system call or modify the time or date in a response to a “time-of-day” system call to a future time or date. Alternatively, the computing system 120 can identify a time consuming program loop (e.g., a long, central processing unit intensive while loop) executing in the computing system 120 and can increase the priority of the software program containing the program loop to accelerate execution of the program loop.


In various embodiments, the computer worm sensor 105 includes one or more computer programs for identifying execution anomalies in the computing systems 120 (e.g., anomalous behavior in the computer network 110) and distinguishing a propagation vector of a computer worm from spurious traffic (e.g. chaff traffic) generated by the computer worm. In one embodiment, the computing systems 120 execute the computing programs to identify execution anomalies occurring in the computing network 110. The computer worm sensor 105 correlates these execution anomalies with the monitored behavior of the computer worm to distinguish computing processes (e.g., network services) that the computer worm exploits for propagation purposes from computing processes that only receive benign network traffic from the computer worm. The computer worm sensor 105 then determines a propagation vector of the computer worm based on the computing processes that the computer worm propagates for exploitative purposes. In a further embodiment, each computing system 120 executing one of the computer programs function as an intrusion detection system (IDS) by generating a computer worm intrusion indicator in response to detecting an execution anomaly.


In one embodiment, the computer worm sensor 105 tracks system call sequences to identify an execution anomaly in the computing system 120. For example, the computer worm sensor 105 can use finite state automata techniques to identify an execution anomaly. Additionally, the computer worm system 105 may identify an execution anomaly based on call-stack information for system calls executed in a computing system 120. For example, a call-stack execution anomaly may occur when a computer worm executes system calls from the stack or the heap of the computing system 120. The computer worm system 105 may also identify an execution anomaly based on virtual path identifiers in the call-stack information.


The computer worm system 105 may monitor transport level ports of a computing system 120. For example, the computer worm sensor 105 can monitor systems calls (e.g., “bind” or “recvfrom” system calls) associated with one or more transport level ports of a computing process in the computing system 120 to identify an execution anomaly. If the computer worm system 105 identifies an execution anomaly for one of the transport level ports, the computer worm sensor 105 includes the transport level port in the identifier (e.g., a signature or a vector) of the computer worm, as is described more fully herein.


In another embodiment, the computer worm sensor 105 analyzes binary code (e.g., object code) of a computing process in the computing system 120 to identify an execution anomaly. The computer worm system 105 may also analyze the call stack and the execution stack of the computing system 120 to identify the execution anomaly. For example, the computer worm sensor 105 may perform a static analysis on the binary code of the computing process to identify possible call stacks and virtual path identifiers for the computing process. The computer worm sensor 105 then compares an actual call stack with the identified call stacks to identify a call stack execution anomaly in the computing system 120. In this way, the computer worm sensor 105 can reduce the number of false positive computer worm detections (e.g., detection of computer worms not in the computing system 120) and false negative computer worm detections (i.e., failure to detect computer worms in the computing system 120). Moreover, if the computer worm sensor 105 can identify all possible call-stacks and virtual path identifiers for the computing process, the computer worm sensor 105 can have a zero false positive rate of computer worm detection.


In another embodiment, the computer worm sensor 105 identifies one or more anomalous program counters in the call stack. For example, an anomalous program counter can be the program counter of a system call generated by worm code of a computer worm. The computer worm sensor 105 tracks the anomalous program counters and determines an identifier for detecting the computer worm based on the anomalous program counters. Additionally, the computer worm sensor 105 may determine whether a memory location (e.g., a memory address or a memory page) referenced by the program counter is a writable memory location. The computer worm sensor 105 then determines whether the computer worm has exploited the memory location. For example, a computer worm can store worm code into a memory location by exploiting a vulnerability of the computing system 120 (e.g., a buffer overflow mechanism).


The computer worm sensor 105 may take a snapshot of data in the memory around the memory location referenced by the anomalous program counter. The computer worm sensor 105 then searches the snapshot for data in recent data packets received by the computing process (e.g., computing thread) associated with the anomalous program counter. The computer worm sensor 105 searches the snapshot by using a searching algorithm to compare data in the recent data packets with a sliding window of data (e.g., 16 bytes of data) in the snapshot. If the computer worm sensor 105 finds a match between the data in a recent data packet and the data in the sliding window, the matching data is deemed a signature candidate for the computer worm.


In another embodiment, the computing system 120 tracks the integrity of computing code in a computing system 120 to identify an execution anomaly in the computing system 120. The computing system 120 associates an integrity value with data stored in the computing system 120 to identify the source of the data. If the data is from a known source (e.g., a computing program) in the computing system 120, the integrity value is set to one, otherwise the integrity value is set to zero. For example, data received by the computing system 120 in a network communication is associated with an integrity value of zero. The computing system 120 stores the integrity value along with the data in the computing system 120, and monitors a program counter in the computing system 120 to identify an execution anomaly based on the integrity value. A program counter having an integrity value of zero indicates that data from a network communication is stored in the program counter, which represents an execution anomaly in the computing system 120.


The computing system 120 may use the signature extraction algorithm to identify a decryption routine in the worm code of a polymorphic worm, such that the decryption routine is deemed a signature candidate of the computer worm. Additionally, the computer worm sensor 105 may compare signature candidates identified by the computing systems 120 in the computer worm sensor 105 to determine an identifier for detecting the computer worm. For example, the computer worm sensor 105 can identify common code portions in the signature candidates to determine an identifier for detecting the computer worm. In this way, the computer worm sensor 105 can determine an identifier of a polymorphic worm containing a mutating decryption routine (e.g., polymorphic code).


In another embodiment, the computer worm sensor 105 monitors network traffic in the computer network 110 and compares the monitored network traffic with typical network traffic patterns occurring in a computer network to identify anomalous network traffic in the computer network 110. The computer worm sensor 105 determines signature candidates based on data packets of the anomalous network traffic (e.g., extracts signature candidates from the data packets) and determines identifiers for detecting the computer worms based on the signature candidates.


In another embodiment, the computer worm sensor 105 evaluates characteristics of a signature candidate to determine the quality of the signature candidate, which indicates an expected level of false positive computer worm detection in a computer network (e.g., the communication network 130). For example, a signature candidate having a high quality is not contained in data packets of typical network traffic occurring in the computer network. Characteristics of a signature candidate include a minimum length of the signature candidate (e.g., 16 bytes of data) and an unusual data byte sequence. In one embodiment, the computer worm sensor 105 performs statistical analysis on the signature candidate to determine whether the signature candidate includes an unusual byte sequence. For example, computer worm sensor 105 can determine a correlation between the signature candidate and data contained in typical network traffic. In this example, a low correlation (e.g., zero correlation) indicates a high quality signature candidate.


In another embodiment, the computer worm sensor 105 identifies execution anomalies by detecting unexpected computing processes in the computer network 110 (i.e., computing processes that are not part of the orchestrated behavior of the computing network 110). The operating systems in the computing systems 120 may be configured to detect computing processes that are not in a predetermined collection of computing processes. In another embodiment, a computing system 120 is configured as a network server that permits a host in the communication network 130 to remotely executed commands on the computing system 120. For example, the original Morris computer worm exploited a debug mode of sendmail that allowed remote command execution in a mail server.


In some cases, the intrusion detection system of the computer worm sensor 105 detects an active computer worm based on anomalous network traffic in the computer network 110, but the computer worm sensor 105 does not detect an execution anomaly caused by a computing process in the computer network 110. In these cases, the computer worm sensor 105 determines whether the computer worm has multiple possible transport vectors based on the ports being accessed by the anomalous network traffic in the computer network 110. If the computer network 110 includes a small number (e.g., one or two) of ports, the computer worm sensor 105 can use these ports to determine a vector for the computer worm. Conversely, if the computer network 110 includes many ports (e.g., three or more ports), the computer worm sensor 105 partitions the computing services in the computer network 110 at appropriate control points to determine those ports exploited by the computer worm.


The computer worm sensor 105 may randomly blocks ports of the computing systems 120 to suppress traffic to these blocked ports. Consequently, a computer worm having a transport vector that requires one or more of the blocked ports will not be able to infect a computing system 120 in which those ports are blocked. The computer worm sensor 105 then correlates the anomalous behavior of the computer worm across the computing systems 120 to determine which ports the computer worm has used for diversionary purposes (e.g., emitting chaff) and which ports the computer worm has used for exploitive purposes. The computer worm sensor 105 then determines a transport vector of the computer worm based on the ports that the computer worm has used for exploitive purposes.



FIG. 2 depicts an exemplary embodiment of the controller 115. The controller 115 includes an extraction unit 200, an orchestration engine 205, a database 210, and a software configuration unit 215. The extraction unit 200, the orchestration engine 205, the database 210, and the computer network 110 (FIG. 1) are in communication with each other and with the computer network 110. Optionally, the controller 115 includes a protocol sequence replayer 220 in communication with the computer network 110 and the traffic analysis device 135 (FIG. 1).


In various embodiments, the orchestration engine 205 controls the state and operation of the computer worm sensor 105 (FIG. 1). In one embodiment, the orchestration engine 205 configures the computing systems 120 (FIG. 1) and the gateway 125 (FIG. 1) to operate in a predetermined manner in response to network activities occurring in the computer network 110, and generates network activities in the computer network 110 and the communication network 130 (FIG. 1). In this way, the orchestration engine 205 orchestrates network activities in the computer network 110. For example, the orchestration engine 205 may orchestrate network activities in the computer network 110 by generating an orchestration sequence (e.g., a predetermined sequence of network activities) among various computing systems 120 in the computer network 110, including network traffic that typically occurs in the communication network 130.


In one embodiment, the orchestration engine 205 sends orchestration requests (e.g., orchestration patterns) to various orchestration agents (e.g., computing processes) in the computing systems 120. The orchestration agent of a computing system 120 performs a periodic sweep of computing services (e.g., network services) in the computing system 120 that are potential targets of a computer worm attack. The computing services in the computing system 120 may include typical network services (e.g., web service, FTP service, mail service, instant messaging, or Kazaa) that are also in the communication network 130.


The orchestration engine 205 may generate a wide variety of orchestration sequences to exercise a variety of computing services in the computer network 110, or may select orchestration patterns to avoid loading the communication network 110 with orchestrated network traffic. Additionally, the orchestration engine 205 may select the orchestration patters to vary the orchestration sequences. In this way, a computer worm is prevented from scanning the computer network 110 to predict the behavior of the computer network 110.


In various embodiments, the software configuration unit 215 dynamically creates or destroys virtual machines (VMs) or VM software profiles in the computer network 110, and may initialize or update the software state of the VMs or VM software profiles. In this way, the software configuration unit 215 configures the computer network 110 such that the controller 115 can orchestrate network activities in computer network 110 based on one or more orchestration patterns. It is to be appreciated that the software configuration unit 215 is optional in various embodiments of the computer worm sensor 105.


In various embodiments, the extraction unit 200 determines an identifier for detecting the computer worm. In these embodiments, the extraction unit 200 can extract a signature or a vector of the computer worm based on network activities (e.g., an anomalous behavior) occurring in the computer network 110, for example from data (e.g., data packets) in a network communication.


The database 210 stores data for the computer worm sensor 105, which may include a configuration state of the computer worm sensor 105. For example, the configuration state may include orchestration patterns or “golden” software images of computer programs (i.e., original software images uncorrupted by a computer worm exploit). The data stored in the database 210 may also include identifiers or recovery scripts for computer worms, or identifiers for the sources of computer worms in the communication network 130. The identifier for the source of each computer worm may be associated with the identifier and the recovery script of the computer worm.


The protocol sequence replayer 220 receives a network communication from the traffic analysis device 135 (FIG. 1) representing a network communication in the communication network 130 and replays (i.e., duplicates) the network communication in the computer network 110. The protocol sequence replayer 220 may receive the network communication from the traffic analysis device 125 via a private encrypted network (e.g., a virtual private network) within the communication network 130 or via another communication network. The controller 115 monitors the behavior of the computer network 110 in response to the network communication to determine a monitored behavior of the computer network 110 and determine whether the monitored behavior includes an anomalous behavior, as is described more fully herein.


In one embodiment, the protocol sequence replayer 220 includes a queue 225 for storing network communications. The queue 225 receives network a communication from the traffic analysis device 135 and temporarily stores the network communication until the protocol sequence replayer 220 is available to replay the network communication. In another embodiment, the protocol sequence replayer 220 is a computing system 120 in the computer network 110. For example, the protocol sequence replayer 200 may be a computer server including computer program code for replaying network communications in the computer network 110.


In another embodiment, the protocol sequence replayer 220 is in communication with a port (e.g., connected to a network port) of a network device in the communication network 130 and receives duplicated network communications occurring in the communication network 130 from the port. For example, the port can be a Switched Port Analyzer (SPAN) port of a network switch or a network router in the communication network 130, which duplicates network traffic in the communication network 130. In this way, various types of active and passive computer worms (e.g., hit-list directed, topologically-directed, server-directed, and scan-directed computer worms) may propagate from the communication network 130 to the computer network 110 via the duplicated network traffic.


The protocol sequence replayer 220 replays the data packets in the computer network 110 by sending the data packets to a computing system 120 having the same class (e.g., Linux or Windows platform) as the original target system of the data packets. In various embodiments, the protocol network replayer 220 synchronizes any return network traffic generated by the computing system 120 in response to the data packets. The protocol sequence replayer 220 may suppress (e.g., discard) the return network traffic such that the return network traffic is not transmitted to a host in the communication network 130. In one embodiment, the protocol sequence replayer 220 replays the data packets by sending the data packets to the computing system 120 via a TCP connection or UDP session. In this embodiment, the protocol sequence replayer 220 synchronizes return network traffic by terminating the TCP connection or UDP session.


The protocol sequence replayer 220 may modify destination IP addresses of data packets in the network communication to one or more IP addresses of the computing systems 120 and replay (i.e., generate) the modified data packets in the computer network 110. The controller 115 monitors the behavior of the computer network 110 in response to the modified data packets, and may detect an anomalous behavior in the monitored behavior, as is described more fully herein. If the controller 115 identifies an anomalous behavior, the computer network 110 is deemed infected with a computer worm and the controller 115 determines an identifier for the computer worm, as is described more fully herein.


The protocol sequence replayer 220 may analyze (e.g., examine) data packets in a sequence of network communications in the communication network 130 to identify a session identifier. The session identifier identifies a communication session for the sequence of network communications and can distinguish the network communications in the sequence from other network communications in the communication network 130. For example, each communication session in the communication network 130 can have a unique session identifier. The protocol sequence replayer 220 may identify the session identifier based on the communication protocol of the network communications in the sequence. For example, the session identifier may be in a field of a data packet header as specified by the communication protocol. Alternatively, the protocol sequence replayer 220 may infer the session identifier from repeating network communications in the sequence. For example, the session identifier is typically one of the first fields in an application level communication between a client and a server (e.g., computing system 120) and is repeatedly used in subsequent communications between the client and the server.


The protocol sequence replayer 220 may modify the session identifier in the data packets of the sequence of network communications. The protocol sequence replayer 220 generates an initial network communication in the computer network 110 based on a selected network communication in the sequence, and the computer network 110 (e.g., a computing system 120) generates a response including a session identifier. The protocol sequence replayer 220 then substitutes the session identifier in the remaining data packets of the network communication with the session identifier of the response. In a further embodiment, the protocol sequence replayer 220 dynamically modifies session variables in the data packets, as is appropriate, to emulate the sequence of network communications in the computer network 110.


The protocol sequence replayer 220 may determine the software or hardware profile of a host (e.g., a computing system) in the communication network 130 to which the data packets of the network communication are directed. The protocol sequence replayer 220 then selects a computing system 120 in the computer network 110 that has the same software or hardware profile of the host and performs dynamic NAT on the data packets to redirect the data packets to the selected computing system 120. Alternatively, the protocol sequence replayer 220 randomly selects a computing system 120 and performs dynamic NAT on the data packets to redirect the data packets to the randomly selected computing system 120.


In one embodiment, the traffic analysis device 135 can identify a request (i.e., a network communication) from a web browser to a web server in the communication network 130, and a response (i.e., a network communication) from the web server to the web browser. In this case, the response may include a passive computer worm. The traffic analysis device 135 may inspect web traffic on a selected network link in the communication network 130 to identify the request and response. For example, the traffic analysis device 135 may select the network link or identify the request based on a policy. The protocol sequence replayer 220 orchestrates the request in the computer network 110 such that a web browser in a computing system 120 indicates a substantially similar request. In response to this request, the protocol sequence replayer 220 generates a response to the web browser in the computing system 120, which is substantially similar to the response generated by the browser in the communication network 130. The controller 115 then monitors the behavior of the web browser in the computing system 120 and may identify an anomalous behavior in the monitored behavior. If the controller 115 identifies an anomalous behavior, the computer network 110 is deemed infected with a passive computer worm.



FIG. 3 depicts an exemplary computer worm detection system 300. The computer worm detection system 300 includes multiple computer worm sensors 105 and a sensor manager 305. Each of the computer worm sensors 105 is in communication with the sensor manager 305 and the communication network 130. The sensor manager 305 coordinates communications or operations between the computer worm sensors 105.


In one embodiment, each computer worm sensor 105 randomly blocks one or more ports of the computing systems 120. Accordingly, some of the worm sensors 105 may detect an anomalous behavior of a computer worm, as is described more fully herein. The worm sensors 105 that detect an anomalous behavior communicate the anomalous behavior (e.g., a signature candidate) to the sensor manager 305. In turn, the sensor manager 305 correlates the anomalous behaviors and determines an identifier (e.g., a transport vector) for detecting the computer worm.


In some cases, a human intruder (e.g., a computer hacker) may attempt to exploit vulnerabilities that a computer worm would exploit in a computer worm sensor 105. The sensor manager 305 may distinguish an anomalous behavior of a human intruder from an anomalous behavior of a computer worm by tracking the number of computing systems 120 in the computer worm sensors 105 that detect a computer worm within a given period. If the number of computing systems 120 detecting a computer worm within the given period exceeds a predetermined threshold, the sensor manager 305 determines that a computer worm caused the anomalous behavior. Conversely, if the number of computing systems 120 detecting a computer worm within the given period is equal to or less than the predetermined threshold, the sensor manager 300 determines that a human intruder caused the anomalous behavior. In this way, false positive detections of the computer worm may be decreased.


In one embodiment, each computer worm sensor 105 maintains a list of infected hosts (e.g., computing systems infected by a computer worm) in the communication network 130 and communicates the list to the sensor manager 305. In this way, computer worm detection system 300 maintains a list of infected hosts detected by the computer worm sensors 105.



FIG. 4 depicts a flow chart for an exemplary method of detecting computer worms, in accordance with one embodiment of the present invention. In step 400, the computer worm sensor 105 (FIG. 1) orchestrates a sequence of network activities in the computer network 110 (FIG. 1). For example, the orchestration engine 205 (FIG. 2) of the computer worm sensor 105 can orchestrate the sequence of network activity in the computer network 110 based on one or more orchestration patterns, as is described more fully herein.


In step 405, the controller 115 (FIG. 1) of the computer worm sensor 105 monitors the behavior of the computer network 110 in response to the predetermined sequence of network activity. For example, the orchestration engine 205 (FIG. 2) of the computer worm sensor 105 can monitor the behavior of the computer network 110. The monitored behavior of the computer network 110 may include one or more network activities in addition to the predetermined sequence of network activities or network activities that differ from the predetermined sequence of network activities.


In step 410, the computer worm sensor 105 identifies an anomalous behavior in the monitored behavior to detect a computer worm. In one embodiment, the controller 115 identifies the anomalous behavior by comparing the predetermined sequence of network activities with network activities in the monitored behavior. For example, the orchestration engine 205 of the controller 115 can identify the anomalous behavior by comparing network activities in the monitored behavior with one or more orchestration patterns defining the predetermined sequence of network activities. The computer worm sensor 105 evaluates the anomalous behavior to determine whether the anomalous behavior is caused by a computer worm, as is described more fully herein.


In step 415, the computer worm sensor 105 determines an identifier for detecting the computer worm based on the anomalous behavior. The identifier may include a signature or a vector of the computer worm, or both. For example, the vector can be a transport vector, an attack vector, or a payload vector. In one embodiment, the extraction unit 200 of the computer worm sensor 105 determines the signature of the computer worm based on one or more signature candidates, as is described more fully herein. It is to be appreciated that step 415 is optional in accordance with various embodiments of the computer worm sensor 105.


In step 420, the computer worm sensor 105 generates a recovery script for the computer worm. An infected host (e.g., an infected computing system or network) can then execute the recovery script to disable (e.g., destroy) the computer worm in the infected host or repair damage to the host caused by the computer worm. The computer worm sensor 105 may also identify a host in the communication network 130 that is the source of the computer worm and provides the recovery script to the host such that the host can disable the computer worm and repair damage to the host caused by the computer worm.


In one embodiment, the controller 115 determines a current image of the file system in the computer network 120, and compares the current image with an original image of the file system in the computer network 120 to identify any discrepancies between the current image and the original image. The controller 115 then generates the recovery script based on these discrepancies. The recovery script includes computer program code for identifying infected software programs or memory locations based on the discrepancies, and removing the discrepancies from infected software programs or memory locations.


The embodiments discussed herein are illustrative of the present invention. As these embodiments of the present invention are described with reference to illustrations, various modifications or adaptations of the methods and/or specific structures described may become apparent to those skilled in the art. All such modifications, adaptations, or variations that rely upon the teachings of the present invention, and through which these teachings have advanced the art, are considered to be within the spirit and scope of the present invention. Hence, these descriptions and drawings should not be considered in a limiting sense, as it is understood that the present invention is in no way limited to only the embodiments illustrated.

Claims
  • 1. A system comprising: one or more sensors, each sensor including (i) a virtualized network including one or more virtual machines each including software maintained within a non-transitory memory storage device associated with the one or more virtual machines that supports message exchanges with one or more other virtual machines within the virtualized network, and (ii) a controller configured to orchestrate activities within the virtualized network and monitor one or more behaviors detected within the virtualized network; anda sensor manager communicatively coupled to the one or more sensors, the sensor manager to coordinate communications or operations among the one or more sensors,wherein a sensor of the one or more sensors is configured to monitor behaviors of at least a first virtual machine corresponding to a first computing system by at least monitoring network activities conducted by information being processed within the first virtual machine to determine an anomalous behavior by at least the first virtual machine.
  • 2. The system of claim 1, wherein the one or more sensors correspond to a plurality of sensors.
  • 3. The system of claim 1, wherein the controller is further configured to generate a signature to detect malware in network traffic propagating over a communication network.
  • 4. The system of claim 1, wherein the anomalous behavior constitutes an execution anomaly.
  • 5. The system of claim 1, wherein the one or more sensors and the sensor manager constitute software maintained within the non-transitory memory storage device.
  • 6. The system of claim 1, wherein the controller of a sensor of the one or more sensors is configured to identify a source of malware infecting the virtualized network and transmit a recovery script to the source, the recovery script includes software configured to (i) identify one or more infected software programs or memory locations of the source and (ii) remove the one or more infected software programs or memory locations.
  • 7. The system of claim 1, wherein a sensor of the one or more sensors includes a probe mechanism to automatically check one or more properties of application software components installed in network devices communicatively coupled to a communication network.
  • 8. The system of claim 7, wherein the one or more properties include one or more of (i) a version, (ii) a release number, and (iii) a patch-level of operating systems and application software components installed with network devices connected to the communication network.
  • 9. The system of claim 1, wherein each of the one or more virtual machines includes the software operating as a driver software that supports the message exchanges.
  • 10. The system of claim 1, wherein a first sensor of the one or more sensors being configured to accelerate activities in the virtualized network in order to reduce a time for detecting a time-delayed malware.
  • 11. A system comprising: a first sensor including (i) a virtualized network including one or more virtual machines each including software maintained within a non-transitory memory storage device associated with the one or more virtual machines that supports message exchanges with one or more other virtual machines within the virtualized network, and (ii) a controller configured to orchestrate activities within the virtualized network and monitor one or more behaviors detected within the virtualized network, wherein the sensor being configured to accelerate activities in the virtualized network in order to reduce a time for detecting a time-delayed malware; anda sensor manager configured to be communicatively coupled to at least the first sensor, the sensor manager to coordinate communications or operations between the first sensor and a second sensor different than the first sensor.
  • 12. The system of claim 11, wherein the controller is further configured to generate a signature to detect malware in network traffic propagating over a communication network.
  • 13. The system of claim 11, wherein the first sensor is configured to monitor behaviors of at least a first virtual machine corresponding to a first computing system of the one or more computing systems to determine an execution anomaly.
  • 14. The system of claim 13, wherein the first sensor is configured to monitor the behaviors of at least the first virtual machine by at least monitoring network activities conducted by information being processed within the first virtual machine.
  • 15. The system of claim 11, wherein the controller of the first sensor is configured to identify a source of malware infecting the virtualized network and transmit a recovery script to the source, the recovery script includes software configured to (i) identify one or more infected software programs or memory locations of the source and (ii) remove the one or more infected software programs or memory locations.
  • 16. The system of claim 11, wherein the first sensor includes a probe mechanism to automatically check one or more properties of application software components installed in network devices communicatively coupled to a communication network.
  • 17. The system of claim 16, wherein the one or more properties include one or more of (i) a version, (ii) a release number, and (iii) a patch-level of operating systems and application software components installed with network devices connected to the communication network.
  • 18. The system of claim 11, wherein each of the one or more virtual machines includes the software operating as a driver software that supports the message exchanges.
  • 19. A system comprising: a non-transitory memory storage device;one or more sensors being software maintained within the non-transitory memory storage device, each sensor including (i) a virtualized network including one or more virtual machines each including software that, when in operation, supports message exchanges with one or more other virtual machines within the virtualized network, and (ii) a controller configured to orchestrate activities within the virtualized network and monitor one or more behaviors detected within the virtualized network; anda sensor manager being software maintained within the non-transitory memory storage device, the sensor manager to coordinate communications or operations among the one or more sensors,wherein a sensor of the one or more sensors is configured to monitor behaviors of at least a first virtual machine corresponding to a first computing system by at least monitoring network activities conducted by information being processed within the first virtual machine to determine at least an execution anomaly or a communication anomaly.
  • 20. The system of claim 19, wherein the controller of the sensor is configured to identify a source of malware infecting the virtualized network and transmit a recovery script to the source or the sensor, the recovery script includes software configured to (i) identify one or more infected software programs or memory locations and (ii) remove the one or more infected software programs or memory locations.
  • 21. The system of claim 19, wherein the sensor includes a probe mechanism to automatically check one or more properties of application software components installed in network devices communicatively coupled to a communication network.
  • 22. The system of claim 21, wherein the one or more properties include one or more of (i) a version, (ii) a release number, and (iii) a patch-level of operating systems and application software components installed with network devices connected to the communication network.
  • 23. The system of claim 19, wherein each of the one or more virtual machines includes the software operating as a driver software that supports the message exchanges.
  • 24. The system of claim 19, wherein a first sensor of the one or more sensors being configured to accelerate activities in the virtualized network in order to reduce a time for detecting a time-delayed malware.
CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 15/225,669 filed Aug. 1, 2016, now U.S. Pat. No. 10,567,405 issued Feb. 18, 2020, which is a continuation of U.S. patent application Ser. No. 15/167,645 filed May 27, 2016, which is a continuation of U.S. patent application Ser. No. 13/931,633 filed Jun. 28, 2013, now U.S. Pat. No. 9,356,944, which is a continuation of U.S. patent application Ser. No. 11/096,287 filed Mar. 31, 2005, now U.S. Pat. No. 8,528,086, which claims the benefit of priority on U.S. provisional patent application No. 60/559,198, filed Apr. 1, 2004 and entitled “System and Method of Detecting Computer Worms,” the entire contents of all of which are incorporated by reference herein.

US Referenced Citations (723)
Number Name Date Kind
4292580 Ott et al. Sep 1981 A
5175732 Hendel et al. Dec 1992 A
5319776 Hile et al. Jun 1994 A
5440723 Arnold et al. Aug 1995 A
5490249 Miller Feb 1996 A
5657473 Killean et al. Aug 1997 A
5802277 Cowlard Sep 1998 A
5842002 Schnurer et al. Nov 1998 A
5960170 Chen et al. Sep 1999 A
5978917 Chi Nov 1999 A
5983348 Ji Nov 1999 A
6088803 Tso et al. Jul 2000 A
6092194 Touboul Jul 2000 A
6094677 Capek et al. Jul 2000 A
6108799 Boulay et al. Aug 2000 A
6118382 Hibbs et al. Sep 2000 A
6154844 Touboul et al. Nov 2000 A
6269330 Cidon et al. Jul 2001 B1
6272641 Ji Aug 2001 B1
6279113 Vaidya Aug 2001 B1
6298445 Shostack et al. Oct 2001 B1
6357008 Nachenberg Mar 2002 B1
6417774 Hibbs et al. Jul 2002 B1
6424627 Sørhaug et al. Jul 2002 B1
6442696 Wray et al. Aug 2002 B1
6484315 Ziese Nov 2002 B1
6487666 Shanklin et al. Nov 2002 B1
6493756 O'Brien et al. Dec 2002 B1
6550012 Villa et al. Apr 2003 B1
6700497 Hibbs et al. Mar 2004 B2
6775657 Baker Aug 2004 B1
6831893 Ben Nun et al. Dec 2004 B1
6832367 Choi et al. Dec 2004 B1
6895550 Kanchirayappa et al. May 2005 B2
6898632 Gordy et al. May 2005 B2
6907396 Muttik et al. Jun 2005 B1
6941348 Petry et al. Sep 2005 B2
6971097 Wallman Nov 2005 B1
6981279 Arnold Dec 2005 B1
6995665 Appelt et al. Feb 2006 B2
7007107 Ivchenko et al. Feb 2006 B1
7028179 Anderson et al. Apr 2006 B2
7043757 Hoefelmeyer et al. May 2006 B2
7058822 Edery et al. Jun 2006 B2
7069316 Gryaznov Jun 2006 B1
7080407 Zhao et al. Jul 2006 B1
7080408 Pak et al. Jul 2006 B1
7093002 Wolff et al. Aug 2006 B2
7093239 van der Made Aug 2006 B1
7096498 Judge Aug 2006 B2
7100201 Izatt Aug 2006 B2
7107617 Hursey et al. Sep 2006 B2
7159149 Spiegel et al. Jan 2007 B2
7213260 Judge May 2007 B2
7231667 Jordan Jun 2007 B2
7240364 Branscomb et al. Jul 2007 B1
7240368 Roesch et al. Jul 2007 B1
7243371 Kasper et al. Jul 2007 B1
7249175 Donaldson Jul 2007 B1
7251215 Turner et al. Jul 2007 B1
7287278 Liang Oct 2007 B2
7308716 Danford et al. Dec 2007 B2
7328453 Merkle, Jr. et al. Feb 2008 B2
7346486 Ivancic et al. Mar 2008 B2
7356736 Natvig Apr 2008 B2
7386888 Liang et al. Jun 2008 B2
7392542 Bucher Jun 2008 B2
7418729 Szor Aug 2008 B2
7428300 Drew et al. Sep 2008 B1
7441272 Durham et al. Oct 2008 B2
7448084 Apap et al. Nov 2008 B1
7458098 Judge et al. Nov 2008 B2
7464404 Carpenter et al. Dec 2008 B2
7464407 Nakae et al. Dec 2008 B2
7467408 O'Toole, Jr. Dec 2008 B1
7478428 Thomlinson Jan 2009 B1
7480773 Reed Jan 2009 B1
7487543 Arnold et al. Feb 2009 B2
7496960 Chen et al. Feb 2009 B1
7496961 Zimmer et al. Feb 2009 B2
7519990 Xie Apr 2009 B1
7523493 Liang et al. Apr 2009 B2
7530104 Thrower et al. May 2009 B1
7540025 Tzadikario May 2009 B2
7546638 Anderson et al. Jun 2009 B2
7565550 Liang et al. Jul 2009 B2
7568233 Szor et al. Jul 2009 B1
7584455 Ball Sep 2009 B2
7603715 Costa et al. Oct 2009 B2
7607171 Marsden et al. Oct 2009 B1
7639714 Stolfo et al. Dec 2009 B2
7644441 Schmid et al. Jan 2010 B2
7657419 van der Made Feb 2010 B2
7676841 Sobchuk et al. Mar 2010 B2
7698548 Shelest et al. Apr 2010 B2
7707633 Danford et al. Apr 2010 B2
7712136 Sprosts et al. May 2010 B2
7730011 Deninger et al. Jun 2010 B1
7739740 Nachenberg et al. Jun 2010 B1
7779463 Stolfo et al. Aug 2010 B2
7784097 Stolfo et al. Aug 2010 B1
7832008 Kraemer Nov 2010 B1
7836502 Zhao et al. Nov 2010 B1
7849506 Dansey et al. Dec 2010 B1
7854007 Sprosts et al. Dec 2010 B2
7869073 Oshima Jan 2011 B2
7877803 Enstone et al. Jan 2011 B2
7904959 Sidiroglou et al. Mar 2011 B2
7908660 Bahl Mar 2011 B2
7930738 Petersen Apr 2011 B1
7937387 Frazier et al. May 2011 B2
7937761 Bennett May 2011 B1
7949849 Lowe et al. May 2011 B2
7996556 Raghavan et al. Aug 2011 B2
7996836 McCorkendale et al. Aug 2011 B1
7996904 Chiueh et al. Aug 2011 B1
7996905 Arnold et al. Aug 2011 B2
8006305 Aziz Aug 2011 B2
8010667 Zhang et al. Aug 2011 B2
8020206 Hubbard et al. Sep 2011 B2
8028338 Schneider et al. Sep 2011 B1
8042184 Batenin Oct 2011 B1
8045094 Teragawa Oct 2011 B2
8045458 Alperovitch et al. Oct 2011 B2
8069484 McMillan et al. Nov 2011 B2
8087086 Lai et al. Dec 2011 B1
8171553 Aziz et al. May 2012 B2
8176049 Deninger et al. May 2012 B2
8176480 Spertus May 2012 B1
8201246 Wu et al. Jun 2012 B1
8204984 Aziz et al. Jun 2012 B1
8214905 Doukhvalov et al. Jul 2012 B1
8220055 Kennedy Jul 2012 B1
8225288 Miller et al. Jul 2012 B2
8225373 Kraemer Jul 2012 B2
8233882 Rogel Jul 2012 B2
8234640 Fitzgerald et al. Jul 2012 B1
8234709 Viljoen et al. Jul 2012 B2
8239944 Nachenberg et al. Aug 2012 B1
8260914 Ranjan Sep 2012 B1
8266091 Gubin et al. Sep 2012 B1
8286251 Eker et al. Oct 2012 B2
8291499 Aziz et al. Oct 2012 B2
8307435 Mann et al. Nov 2012 B1
8307443 Wang et al. Nov 2012 B2
8312545 Tuvell et al. Nov 2012 B2
8321936 Green et al. Nov 2012 B1
8321941 Tuvell et al. Nov 2012 B2
8332571 Edwards, Sr. Dec 2012 B1
8365286 Poston Jan 2013 B2
8365297 Parshin et al. Jan 2013 B1
8370938 Daswani et al. Feb 2013 B1
8370939 Zaitsev et al. Feb 2013 B2
8375444 Aziz et al. Feb 2013 B2
8381299 Stolfo et al. Feb 2013 B2
8402529 Green et al. Mar 2013 B1
8464340 Ahn et al. Jun 2013 B2
8479174 Chiriac Jul 2013 B2
8479276 Vaystikh et al. Jul 2013 B1
8479291 Bodke Jul 2013 B1
8510827 Leake et al. Aug 2013 B1
8510828 Guo et al. Aug 2013 B1
8510842 Amit et al. Aug 2013 B2
8516478 Edwards et al. Aug 2013 B1
8516590 Ranadive et al. Aug 2013 B1
8516593 Aziz Aug 2013 B2
8522348 Chen et al. Aug 2013 B2
8528086 Aziz Sep 2013 B1
8533824 Hutton et al. Sep 2013 B2
8539582 Aziz et al. Sep 2013 B1
8549638 Aziz Oct 2013 B2
8555391 Demir et al. Oct 2013 B1
8561177 Aziz et al. Oct 2013 B1
8566476 Shiffer et al. Oct 2013 B2
8566946 Aziz et al. Oct 2013 B1
8584094 Dadhia et al. Nov 2013 B2
8584234 Sobel et al. Nov 2013 B1
8584239 Aziz et al. Nov 2013 B2
8595834 Xie et al. Nov 2013 B2
8627476 Satish et al. Jan 2014 B1
8635696 Aziz Jan 2014 B1
8682054 Xue et al. Mar 2014 B2
8682812 Ranjan Mar 2014 B1
8689333 Aziz Apr 2014 B2
8695096 Zhang Apr 2014 B1
8713631 Pavlyushchik Apr 2014 B1
8713681 Silberman et al. Apr 2014 B2
8726392 McCorkendale et al. May 2014 B1
8739280 Chess et al. May 2014 B2
8776229 Aziz Jul 2014 B1
8782792 Bodke Jul 2014 B1
8789172 Stolfo et al. Jul 2014 B2
8789178 Kejriwal et al. Jul 2014 B2
8793278 Frazier et al. Jul 2014 B2
8793787 Ismael et al. Jul 2014 B2
8805947 Kuzkin et al. Aug 2014 B1
8806647 Daswani et al. Aug 2014 B1
8832829 Manni et al. Sep 2014 B2
8850570 Ramzan Sep 2014 B1
8850571 Staniford et al. Sep 2014 B2
8881234 Narasimhan et al. Nov 2014 B2
8881271 Butler, II Nov 2014 B2
8881282 Aziz et al. Nov 2014 B1
8898788 Aziz et al. Nov 2014 B1
8935779 Manni et al. Jan 2015 B2
8949257 Shiffer et al. Feb 2015 B2
8984638 Aziz et al. Mar 2015 B1
8990939 Staniford et al. Mar 2015 B2
8990944 Singh et al. Mar 2015 B1
8997219 Staniford et al. Mar 2015 B2
9009822 Ismael et al. Apr 2015 B1
9009823 Ismael et al. Apr 2015 B1
9027135 Aziz May 2015 B1
9071638 Aziz et al. Jun 2015 B1
9104867 Thioux et al. Aug 2015 B1
9106630 Frazier et al. Aug 2015 B2
9106694 Aziz et al. Aug 2015 B2
9118715 Staniford et al. Aug 2015 B2
9159035 Ismael et al. Oct 2015 B1
9171160 Vincent et al. Oct 2015 B2
9176843 Ismael et al. Nov 2015 B1
9189627 Islam Nov 2015 B1
9195829 Goradia et al. Nov 2015 B1
9197664 Aziz et al. Nov 2015 B1
9223972 Vincent et al. Dec 2015 B1
9225740 Ismael et al. Dec 2015 B1
9241010 Bennett et al. Jan 2016 B1
9251343 Vincent et al. Feb 2016 B1
9262635 Paithane et al. Feb 2016 B2
9268936 Butler Feb 2016 B2
9275229 LeMasters Mar 2016 B2
9282109 Aziz et al. Mar 2016 B1
9292686 Ismael et al. Mar 2016 B2
9294501 Mesdaq et al. Mar 2016 B2
9300686 Pidathala et al. Mar 2016 B2
9306960 Aziz Apr 2016 B1
9306974 Aziz et al. Apr 2016 B1
9311479 Manni et al. Apr 2016 B1
9355247 Thioux et al. May 2016 B1
9356944 Aziz May 2016 B1
9363280 Rivlin et al. Jun 2016 B1
9367681 Ismael et al. Jun 2016 B1
9398028 Karandikar et al. Jul 2016 B1
9413781 Cunningham et al. Aug 2016 B2
9426071 Caldejon et al. Aug 2016 B1
9430646 Mushtaq et al. Aug 2016 B1
9432389 Khalid et al. Aug 2016 B1
9438613 Paithane et al. Sep 2016 B1
9438622 Staniford et al. Sep 2016 B1
9438623 Thioux et al. Sep 2016 B1
9459901 Jung et al. Oct 2016 B2
9467460 Otvagin et al. Oct 2016 B1
9483644 Paithane et al. Nov 2016 B1
9495180 Ismael Nov 2016 B2
9497213 Thompson et al. Nov 2016 B2
9507935 Ismael et al. Nov 2016 B2
9516057 Aziz Dec 2016 B2
9519782 Aziz et al. Dec 2016 B2
9536091 Paithane et al. Jan 2017 B2
9537972 Edwards et al. Jan 2017 B1
9560059 Islam Jan 2017 B1
9565202 Kindlund et al. Feb 2017 B1
9591015 Amin et al. Mar 2017 B1
9591020 Aziz Mar 2017 B1
9594904 Jain et al. Mar 2017 B1
9594905 Ismael et al. Mar 2017 B1
9594912 Thioux et al. Mar 2017 B1
9609007 Rivlin et al. Mar 2017 B1
9626509 Khalid et al. Apr 2017 B1
9628498 Aziz et al. Apr 2017 B1
9628507 Haq et al. Apr 2017 B2
9633134 Ross Apr 2017 B2
9635039 Islam et al. Apr 2017 B1
9641546 Manni et al. May 2017 B1
9654485 Neumann May 2017 B1
9661009 Karandikar et al. May 2017 B1
9661018 Aziz May 2017 B1
9674298 Edwards et al. Jun 2017 B1
9680862 Ismael et al. Jun 2017 B2
9690606 Ha et al. Jun 2017 B1
9690933 Singh et al. Jun 2017 B1
9690935 Shiffer et al. Jun 2017 B2
9690936 Malik et al. Jun 2017 B1
9736179 Ismael Aug 2017 B2
9740857 Ismael et al. Aug 2017 B2
9747446 Pidathala et al. Aug 2017 B1
9756074 Aziz et al. Sep 2017 B2
9773112 Rathor et al. Sep 2017 B1
9781144 Otvagin et al. Oct 2017 B1
9787700 Amin et al. Oct 2017 B1
9787706 Otvagin et al. Oct 2017 B1
9792196 Ismael et al. Oct 2017 B1
9824209 Ismael et al. Nov 2017 B1
9824211 Wilson Nov 2017 B2
9824216 Khalid et al. Nov 2017 B1
9825976 Gomez et al. Nov 2017 B1
9825989 Mehra et al. Nov 2017 B1
9838408 Karandikar et al. Dec 2017 B1
9838411 Aziz Dec 2017 B1
9838416 Aziz Dec 2017 B1
9838417 Khalid et al. Dec 2017 B1
9846776 Paithane et al. Dec 2017 B1
9876701 Caldejon et al. Jan 2018 B1
9888016 Amin et al. Feb 2018 B1
9888019 Pidathala et al. Feb 2018 B1
9910988 Vincent et al. Mar 2018 B1
9912644 Cunningham Mar 2018 B2
9912681 Ismael et al. Mar 2018 B1
9912684 Aziz et al. Mar 2018 B1
9912691 Mesdaq et al. Mar 2018 B2
9912698 Thioux et al. Mar 2018 B1
9916440 Paithane et al. Mar 2018 B1
9921978 Chan et al. Mar 2018 B1
9934376 Ismael Apr 2018 B1
9934381 Kindlund et al. Apr 2018 B1
9946568 Ismael et al. Apr 2018 B1
9954890 Staniford et al. Apr 2018 B1
9973531 Thioux May 2018 B1
10002252 Ismael et al. Jun 2018 B2
10019338 Goradia et al. Jul 2018 B1
10019573 Silberman et al. Jul 2018 B2
10025691 Ismael et al. Jul 2018 B1
10025927 Khalid et al. Jul 2018 B1
10027689 Rathor et al. Jul 2018 B1
10027690 Aziz et al. Jul 2018 B2
10027696 Rivlin et al. Jul 2018 B1
10033747 Paithane et al. Jul 2018 B1
10033748 Cunningham et al. Jul 2018 B1
10033753 Islam et al. Jul 2018 B1
10033759 Kabra et al. Jul 2018 B1
10050998 Singh Aug 2018 B1
10068091 Aziz et al. Sep 2018 B1
10075455 Zafar et al. Sep 2018 B2
10083302 Paithane et al. Sep 2018 B1
10084813 Eyada Sep 2018 B2
10089461 Ha et al. Oct 2018 B1
10097573 Aziz Oct 2018 B1
10104102 Neumann Oct 2018 B1
10108446 Steinberg et al. Oct 2018 B1
10121000 Rivlin et al. Nov 2018 B1
10122746 Manni et al. Nov 2018 B1
10133863 Bu et al. Nov 2018 B2
10133866 Kumar et al. Nov 2018 B1
10146810 Shiffer et al. Dec 2018 B2
10148693 Singh et al. Dec 2018 B2
10165000 Aziz et al. Dec 2018 B1
10169585 Pilipenko et al. Jan 2019 B1
10176321 Abbasi et al. Jan 2019 B2
10181029 Ismael et al. Jan 2019 B1
10191861 Steinberg et al. Jan 2019 B1
10192052 Singh et al. Jan 2019 B1
10198574 Thioux et al. Feb 2019 B1
10200384 Mushtaq et al. Feb 2019 B1
10210329 Malik et al. Feb 2019 B1
10216927 Steinberg Feb 2019 B1
10218740 Mesdaq et al. Feb 2019 B1
10242185 Goradia Mar 2019 B1
10567405 Aziz Feb 2020 B1
20010005889 Albrecht Jun 2001 A1
20010047326 Broadbent et al. Nov 2001 A1
20020018903 Kokubo et al. Feb 2002 A1
20020038430 Edwards et al. Mar 2002 A1
20020091819 Melchione et al. Jul 2002 A1
20020095607 Lin-Hendel Jul 2002 A1
20020116627 Farbotton et al. Aug 2002 A1
20020116635 Sheymov Aug 2002 A1
20020144156 Copeland Oct 2002 A1
20020162015 Tang Oct 2002 A1
20020166063 Lachman et al. Nov 2002 A1
20020169952 DiSanto et al. Nov 2002 A1
20020184528 Shevenell et al. Dec 2002 A1
20020188887 Largman et al. Dec 2002 A1
20020194490 Halperin et al. Dec 2002 A1
20030021728 Sharpe et al. Jan 2003 A1
20030074578 Ford et al. Apr 2003 A1
20030084318 Schertz May 2003 A1
20030101381 Mateev et al. May 2003 A1
20030115483 Liang Jun 2003 A1
20030188190 Aaron et al. Oct 2003 A1
20030191957 Hypponen et al. Oct 2003 A1
20030200460 Morota et al. Oct 2003 A1
20030212902 van der Made Nov 2003 A1
20030217283 Hrastar et al. Nov 2003 A1
20030229801 Kouznetsov et al. Dec 2003 A1
20030237000 Denton et al. Dec 2003 A1
20040003323 Bennett et al. Jan 2004 A1
20040006473 Mills et al. Jan 2004 A1
20040015712 Szor Jan 2004 A1
20040019832 Arnold et al. Jan 2004 A1
20040047356 Bauer Mar 2004 A1
20040064737 Milliken et al. Apr 2004 A1
20040083408 Spiegel et al. Apr 2004 A1
20040088581 Brawn et al. May 2004 A1
20040093513 Cantrell et al. May 2004 A1
20040111531 Staniford et al. Jun 2004 A1
20040117478 Triulzi et al. Jun 2004 A1
20040117624 Brandt et al. Jun 2004 A1
20040128355 Chao et al. Jul 2004 A1
20040165588 Pandya Aug 2004 A1
20040236963 Danford et al. Nov 2004 A1
20040243349 Greifeneder et al. Dec 2004 A1
20040249911 Alkhatib et al. Dec 2004 A1
20040255161 Cavanaugh Dec 2004 A1
20040268147 Wiederin et al. Dec 2004 A1
20050005159 Oliphant Jan 2005 A1
20050021740 Bar et al. Jan 2005 A1
20050033960 Vialen et al. Feb 2005 A1
20050033989 Poletto et al. Feb 2005 A1
20050050148 Mohammadioun et al. Mar 2005 A1
20050086523 Zimmer et al. Apr 2005 A1
20050091513 Mitomo et al. Apr 2005 A1
20050091533 Omote et al. Apr 2005 A1
20050091652 Ross et al. Apr 2005 A1
20050108562 Khazan et al. May 2005 A1
20050114663 Cornell et al. May 2005 A1
20050125195 Brendel Jun 2005 A1
20050149726 Joshi et al. Jul 2005 A1
20050157662 Bingham et al. Jul 2005 A1
20050183143 Anderholm et al. Aug 2005 A1
20050201297 Peikari Sep 2005 A1
20050210533 Copeland et al. Sep 2005 A1
20050238005 Chen et al. Oct 2005 A1
20050240781 Gassoway Oct 2005 A1
20050262562 Gassoway Nov 2005 A1
20050265331 Stolfo Dec 2005 A1
20050283839 Cowbum Dec 2005 A1
20060010495 Cohen et al. Jan 2006 A1
20060015416 Hoffman et al. Jan 2006 A1
20060015715 Anderson Jan 2006 A1
20060015747 Van de Ven Jan 2006 A1
20060021029 Brickell et al. Jan 2006 A1
20060021054 Costa et al. Jan 2006 A1
20060031476 Mathes et al. Feb 2006 A1
20060047665 Neil Mar 2006 A1
20060069912 Zheng Mar 2006 A1
20060070130 Costea et al. Mar 2006 A1
20060075496 Carpenter et al. Apr 2006 A1
20060095968 Portolani et al. May 2006 A1
20060101516 Sudaharan et al. May 2006 A1
20060101517 Banzhof et al. May 2006 A1
20060117385 Mester et al. Jun 2006 A1
20060123477 Raghavan et al. Jun 2006 A1
20060143709 Brooks et al. Jun 2006 A1
20060150249 Gassen et al. Jul 2006 A1
20060161983 Cothrell et al. Jul 2006 A1
20060161987 Levy-Yurista Jul 2006 A1
20060161989 Reshef et al. Jul 2006 A1
20060164199 Gilde et al. Jul 2006 A1
20060173992 Weber et al. Aug 2006 A1
20060179147 Tran et al. Aug 2006 A1
20060184632 Marino et al. Aug 2006 A1
20060191010 Benjamin Aug 2006 A1
20060221956 Narayan et al. Oct 2006 A1
20060236393 Kramer et al. Oct 2006 A1
20060242709 Seinfeld et al. Oct 2006 A1
20060248519 Jaeger et al. Nov 2006 A1
20060248582 Panjwani et al. Nov 2006 A1
20060251104 Koga Nov 2006 A1
20060288417 Bookbinder et al. Dec 2006 A1
20070006288 Mayfield et al. Jan 2007 A1
20070006313 Porras et al. Jan 2007 A1
20070011174 Takaragi et al. Jan 2007 A1
20070016951 Piccard et al. Jan 2007 A1
20070019286 Kikuchi Jan 2007 A1
20070033645 Jones Feb 2007 A1
20070038943 FitzGerald et al. Feb 2007 A1
20070064689 Shin et al. Mar 2007 A1
20070074169 Chess et al. Mar 2007 A1
20070094730 Bhikkaji et al. Apr 2007 A1
20070101435 Konanka et al. May 2007 A1
20070128855 Cho et al. Jun 2007 A1
20070142030 Sinha et al. Jun 2007 A1
20070143827 Nicodemus et al. Jun 2007 A1
20070156895 Vuong Jul 2007 A1
20070157180 Tillmann et al. Jul 2007 A1
20070157306 Elrod et al. Jul 2007 A1
20070168988 Eisner et al. Jul 2007 A1
20070171824 Ruello et al. Jul 2007 A1
20070174915 Gribble et al. Jul 2007 A1
20070192500 Lum Aug 2007 A1
20070192858 Lum Aug 2007 A1
20070198275 Malden et al. Aug 2007 A1
20070208822 Wang et al. Sep 2007 A1
20070220607 Sprosts et al. Sep 2007 A1
20070240218 Tuvell et al. Oct 2007 A1
20070240219 Tuvell et al. Oct 2007 A1
20070240220 Tuvell et al. Oct 2007 A1
20070240222 Tuvell et al. Oct 2007 A1
20070250930 Aziz et al. Oct 2007 A1
20070256132 Oliphant Nov 2007 A2
20070271446 Nakamura Nov 2007 A1
20080005782 Aziz Jan 2008 A1
20080018122 Zierler et al. Jan 2008 A1
20080028463 Dagon et al. Jan 2008 A1
20080032556 Schreier Feb 2008 A1
20080040710 Chiriac Feb 2008 A1
20080046781 Childs et al. Feb 2008 A1
20080066179 Liu Mar 2008 A1
20080072326 Danford et al. Mar 2008 A1
20080077793 Tan et al. Mar 2008 A1
20080080518 Hoeflin et al. Apr 2008 A1
20080086720 Lekel Apr 2008 A1
20080098476 Syversen Apr 2008 A1
20080120722 Sima et al. May 2008 A1
20080134178 Fitzgerald et al. Jun 2008 A1
20080134334 Kim et al. Jun 2008 A1
20080141376 Clausen et al. Jun 2008 A1
20080181227 Todd Jul 2008 A1
20080184367 McMillan et al. Jul 2008 A1
20080184373 Traut et al. Jul 2008 A1
20080189787 Arnold et al. Aug 2008 A1
20080201778 Guo et al. Aug 2008 A1
20080209557 Herley et al. Aug 2008 A1
20080215742 Goldszmidt et al. Sep 2008 A1
20080222729 Chen et al. Sep 2008 A1
20080263665 Ma et al. Oct 2008 A1
20080295172 Bohacek Nov 2008 A1
20080301810 Lehane et al. Dec 2008 A1
20080307524 Singh et al. Dec 2008 A1
20080313738 Enderby Dec 2008 A1
20080320594 Jiang Dec 2008 A1
20090003317 Kasralikar et al. Jan 2009 A1
20090007100 Field et al. Jan 2009 A1
20090013408 Schipka Jan 2009 A1
20090031423 Liu et al. Jan 2009 A1
20090036111 Danford et al. Feb 2009 A1
20090037835 Goldman Feb 2009 A1
20090044024 Oberheide et al. Feb 2009 A1
20090044274 Budko et al. Feb 2009 A1
20090064332 Porras et al. Mar 2009 A1
20090077666 Chen et al. Mar 2009 A1
20090083369 Marmor Mar 2009 A1
20090083855 Apap et al. Mar 2009 A1
20090089879 Wang et al. Apr 2009 A1
20090094697 Proves et al. Apr 2009 A1
20090113425 Ports et al. Apr 2009 A1
20090125976 Wassermann et al. May 2009 A1
20090126015 Monastyrsky et al. May 2009 A1
20090126016 Sobko et al. May 2009 A1
20090133125 Choi et al. May 2009 A1
20090144823 Lamastra et al. Jun 2009 A1
20090158430 Borders Jun 2009 A1
20090172815 Gu et al. Jul 2009 A1
20090187992 Poston Jul 2009 A1
20090193293 Stolfo et al. Jul 2009 A1
20090198651 Shiffer et al. Aug 2009 A1
20090198670 Shiffer et al. Aug 2009 A1
20090198689 Frazier et al. Aug 2009 A1
20090199274 Frazier et al. Aug 2009 A1
20090199296 Xie et al. Aug 2009 A1
20090228233 Anderson et al. Sep 2009 A1
20090241187 Froyansky Sep 2009 A1
20090241190 Todd et al. Sep 2009 A1
20090265692 Godefroid et al. Oct 2009 A1
20090271867 Zhang Oct 2009 A1
20090300415 Zhang et al. Dec 2009 A1
20090300761 Park et al. Dec 2009 A1
20090328185 Berg et al. Dec 2009 A1
20090328221 Blumfield et al. Dec 2009 A1
20100005146 Drako et al. Jan 2010 A1
20100011205 McKenna Jan 2010 A1
20100017546 Poo et al. Jan 2010 A1
20100030996 Butler, II Feb 2010 A1
20100031353 Thomas et al. Feb 2010 A1
20100037314 Perdisci et al. Feb 2010 A1
20100043073 Kuwamura Feb 2010 A1
20100054278 Stolfo et al. Mar 2010 A1
20100058474 Hicks Mar 2010 A1
20100064044 Nonoyama Mar 2010 A1
20100077481 Polyakov et al. Mar 2010 A1
20100083376 Pereira et al. Apr 2010 A1
20100115621 Staniford et al. May 2010 A1
20100132038 Zaitsev May 2010 A1
20100154056 Smith et al. Jun 2010 A1
20100180344 Malyshev et al. Jul 2010 A1
20100192223 Ismael et al. Jul 2010 A1
20100220863 Dupaquis et al. Sep 2010 A1
20100235831 Dittmer Sep 2010 A1
20100251104 Massand Sep 2010 A1
20100281102 Chinta et al. Nov 2010 A1
20100281541 Stolfo et al. Nov 2010 A1
20100281542 Stolfo et al. Nov 2010 A1
20100287260 Peterson et al. Nov 2010 A1
20100299754 Amit et al. Nov 2010 A1
20100306173 Frank Dec 2010 A1
20110004737 Greenebaum Jan 2011 A1
20110025504 Lyon et al. Feb 2011 A1
20110041179 Hlberg Feb 2011 A1
20110047594 Mahaffey et al. Feb 2011 A1
20110047620 Mahaffey et al. Feb 2011 A1
20110055907 Narasimhan et al. Mar 2011 A1
20110078794 Manni et al. Mar 2011 A1
20110093951 Aziz Apr 2011 A1
20110099620 Stavrou et al. Apr 2011 A1
20110099633 Aziz Apr 2011 A1
20110099635 Silberman et al. Apr 2011 A1
20110113231 Kaminsky May 2011 A1
20110145918 Jung et al. Jun 2011 A1
20110145920 Mahaffey et al. Jun 2011 A1
20110145934 Abramovici et al. Jun 2011 A1
20110167493 Song et al. Jul 2011 A1
20110167494 Bowen et al. Jul 2011 A1
20110173213 Frazier et al. Jul 2011 A1
20110173460 Ito et al. Jul 2011 A1
20110219449 St. Neitzel et al. Sep 2011 A1
20110219450 McDougal et al. Sep 2011 A1
20110225624 Sawhney et al. Sep 2011 A1
20110225655 Niemela et al. Sep 2011 A1
20110247072 Staniford et al. Oct 2011 A1
20110265182 Peinado et al. Oct 2011 A1
20110289582 Kejriwal et al. Nov 2011 A1
20110302587 Nishikawa et al. Dec 2011 A1
20110307954 Melnik et al. Dec 2011 A1
20110307955 Kaplan et al. Dec 2011 A1
20110307956 Yermakov et al. Dec 2011 A1
20110314546 Aziz et al. Dec 2011 A1
20120023593 Puder et al. Jan 2012 A1
20120054869 Yen et al. Mar 2012 A1
20120066698 Yanoo Mar 2012 A1
20120079596 Thomas et al. Mar 2012 A1
20120084859 Radinsky et al. Apr 2012 A1
20120096553 Srivastava et al. Apr 2012 A1
20120110667 Zubrilin et al. May 2012 A1
20120117652 Manni et al. May 2012 A1
20120121154 Xue et al. May 2012 A1
20120124426 Maybee et al. May 2012 A1
20120174186 Aziz et al. Jul 2012 A1
20120174196 Bhogavilli et al. Jul 2012 A1
20120174218 McCoy et al. Jul 2012 A1
20120198279 Schroeder Aug 2012 A1
20120210423 Friedrichs et al. Aug 2012 A1
20120222121 Staniford et al. Aug 2012 A1
20120255015 Sahita et al. Oct 2012 A1
20120255017 Sallam Oct 2012 A1
20120260342 Dube et al. Oct 2012 A1
20120266244 Green et al. Oct 2012 A1
20120278886 Luna Nov 2012 A1
20120297489 Dequevy Nov 2012 A1
20120330801 McDougal et al. Dec 2012 A1
20120331553 Aziz et al. Dec 2012 A1
20130014259 Gribble et al. Jan 2013 A1
20130036472 Aziz Feb 2013 A1
20130047257 Aziz Feb 2013 A1
20130074185 McDougal et al. Mar 2013 A1
20130086684 Mohler Apr 2013 A1
20130097699 Balupar et al. Apr 2013 A1
20130097706 Titonis et al. Apr 2013 A1
20130111587 Goel et al. May 2013 A1
20130117852 Stute May 2013 A1
20130117855 Kim et al. May 2013 A1
20130139264 Brinkley et al. May 2013 A1
20130160125 Likhachev et al. Jun 2013 A1
20130160127 Jeong et al. Jun 2013 A1
20130160130 Mendelev et al. Jun 2013 A1
20130160131 Madou et al. Jun 2013 A1
20130167236 Sick Jun 2013 A1
20130174214 Duncan Jul 2013 A1
20130185789 Hagiwara et al. Jul 2013 A1
20130185795 Winn et al. Jul 2013 A1
20130185798 Saunders et al. Jul 2013 A1
20130191915 Antonakakis et al. Jul 2013 A1
20130196649 Paddon et al. Aug 2013 A1
20130227691 Aziz et al. Aug 2013 A1
20130246370 Bartram et al. Sep 2013 A1
20130247186 LeMasters Sep 2013 A1
20130263260 Mahaffey et al. Oct 2013 A1
20130291109 Staniford et al. Oct 2013 A1
20130298243 Kumar et al. Nov 2013 A1
20130318038 Shiffer et al. Nov 2013 A1
20130318073 Shiffer et al. Nov 2013 A1
20130325791 Shiffer et al. Dec 2013 A1
20130325792 Shiffer et al. Dec 2013 A1
20130325871 Shiffer et al. Dec 2013 A1
20130325872 Shiffer et al. Dec 2013 A1
20140032875 Butler Jan 2014 A1
20140053260 Gupta et al. Feb 2014 A1
20140053261 Gupta et al. Feb 2014 A1
20140130158 Wang et al. May 2014 A1
20140137180 Lukacs et al. May 2014 A1
20140169762 Ryu Jun 2014 A1
20140179360 Jackson et al. Jun 2014 A1
20140181131 Ross Jun 2014 A1
20140181970 Belov Jun 2014 A1
20140189687 Jung et al. Jul 2014 A1
20140189866 Shiffer et al. Jul 2014 A1
20140189882 Jung et al. Jul 2014 A1
20140237600 Silberman et al. Aug 2014 A1
20140280245 Wilson Sep 2014 A1
20140283037 Sikorski et al. Sep 2014 A1
20140283063 Thompson et al. Sep 2014 A1
20140328204 Klotsche et al. Nov 2014 A1
20140337836 Ismael Nov 2014 A1
20140344926 Cunningham et al. Nov 2014 A1
20140351935 Shao et al. Nov 2014 A1
20140380473 Bu et al. Dec 2014 A1
20140380474 Paithane et al. Dec 2014 A1
20150007312 Pidathala et al. Jan 2015 A1
20150096022 Vincent et al. Apr 2015 A1
20150096023 Mesdaq et al. Apr 2015 A1
20150096024 Haq et al. Apr 2015 A1
20150096025 Ismael Apr 2015 A1
20150180886 Staniford et al. Jun 2015 A1
20150186645 Aziz et al. Jul 2015 A1
20150199513 Ismael et al. Jul 2015 A1
20150199531 Ismael et al. Jul 2015 A1
20150199532 Ismael et al. Jul 2015 A1
20150220735 Paithane et al. Aug 2015 A1
20150372980 Eyada Dec 2015 A1
20160004869 Ismael et al. Jan 2016 A1
20160006756 Ismael et al. Jan 2016 A1
20160044000 Cunningham Feb 2016 A1
20160127393 Aziz et al. May 2016 A1
20160191547 Zafar et al. Jun 2016 A1
20160191550 Ismael et al. Jun 2016 A1
20160261612 Mesdaq et al. Sep 2016 A1
20160285914 Singh et al. Sep 2016 A1
20160301703 Aziz Oct 2016 A1
20160335110 Paithane et al. Nov 2016 A1
20170083703 Abbasi et al. Mar 2017 A1
20180013770 Ismael Jan 2018 A1
20180048660 Paithane et al. Feb 2018 A1
20180121316 Ismael et al. May 2018 A1
20180288077 Siddiqui et al. Oct 2018 A1
Foreign Referenced Citations (11)
Number Date Country
2439806 Jan 2008 GB
2490431 Oct 2012 GB
0206928 Jan 2002 WO
0223805 Mar 2002 WO
2007117636 Oct 2007 WO
2008041950 Apr 2008 WO
2011084431 Jul 2011 WO
2011112348 Sep 2011 WO
2012075336 Jun 2012 WO
2012145066 Oct 2012 WO
2013067505 May 2013 WO
Non-Patent Literature Citations (100)
Entry
Li et al., A VMM-Based System Call Interposition Framework for Program Monitoring, Dec. 2010, IEEE 16th International Conference on Parallel and Distributed Systems, pp. 706-711.
Liljenstam, Michael , et al., “Simulating Realistic Network Traffic for Worm Warning System Design and Testing”, Institute for Security Technology studies, Dartmouth College (“Liljenstam”), (Oct. 27, 2003).
Lindorfer, Martina, Clemens Kolbitsch, and Paolo Milani Comparetti. “Detecting environment—sensitive malware.” Recent Advances in Intrusion Detection. Springer Berlin Heidelberg, 2011.
Lok Kwong et al: “DroidScope: Seamlessly Reconstructing the OS and Dalvik Semantic Views for Dynamic Android Malware Analysis”, Aug. 10, 2012, XP055158513, Retrieved from the Internet: URL:https://www.usenix.org/system/files/conference/usenixsecurity12/sec12—final107.pdf [retrieved on Dec. 15, 2014].
Marchette, David J., “Computer Intrusion Detection and Network Monitoring: A Statistical Viewpoint”, (“Marchette”), (2001).
Margolis, P.E. , “Random House Webster's 'Computer & Internet Dictionary 3rd Edition ”, ISBN 0375703519, (Dec. 1998).
Moore, D. , et al., “Internet Quarantine: Requirements for Containing Self-Propagating Code”, INFOCOM, vol. 3, (Mar. 30-Apr. 3, 2003), pp. 1901-1910.
Morales, Jose A., et al., ““Analyzing and exploiting network behaviors of malware.””, Security and Privacy in Communication Networks. Springer Berlin Heidelberg, 2010. 20-34.
Mori, Detecting Unknown Computer Viruses, 2004, Springer-Verlag Berlin Heidelberg.
Natvig, Kurt , “SANDBOXII: Internet”, Virus Bulletin Conference, (“Natvig”), (Sep. 2002).
NetBIOS Working Group. Protocol Standard for a NetBIOS Service on a TCP/UDP transport: Concepts and Methods. STD 19, RFC 1001, Mar. 1987.
Newsome, J. , et al., “Dynamic Taint Analysis for Automatic Detection, Analysis, and Signature Generation of Exploits on Commodity Software”, In Proceedings of the 12th Annual Network and Distributed System Security, Symposium (NDSS '05), (Feb. 2005).
Newsome, J. , et al., “Polygraph: Automatically Generating Signatures for Polymorphic Worms”, In Proceedings of the IEEE Symposium on Security and Privacy, (May 2005).
Nojiri, D. , et al., “Cooperation Response Strategies for Large Scale Attack Mitigation”, DARPA Information Survivability Conference and Exposition, vol. 1, (Apr. 22-24, 2003), pp. 293-302.
Oberheide et al., CloudAV.sub.—N-Version Antivirus in the Network Cloud, 17th USENIX Security Symposium USENIX Security '08 Jul. 28-Aug. 1, 2008 San Jose, CA.
Reiner Sailer, Enriquillo Valdez, Trent Jaeger, Roonald Perez, Leendertvan Doorn, John Linwood Griffin, Stefan Berger., sHype: Secure Hypervisor Appraoch to Trusted Virtualized Systems (Feb. 2, 2005) (“Sailer”).
Silicon Defense, “Worm Containment in the Internal Network”, (Mar. 2003), pp. 1-25.
Singh, S. , et al., “Automated Worm Fingerprinting”, Proceedings of the ACM/USENIX Symposium on Operating System Design and Implementation, San Francisco, California, (Dec. 2004).
Spitzner, Lance , “Honeypots: Tracking Hackers”, (“Spizner”), (Sep. 17, 2002).
The Sniffers's Guide to Raw Traffic available at: yuba.stanford.edu/.about.casado/pcap/section1.html, (Jan. 6, 2014).
Thomas H. Ptacek, and Timothy N. Newsham , “Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection”, Secure Networks, (“Ptacek”), (Jan. 1998).
U.S. Appl. No. 11/096,287, filed Mar. 31, 2005 Final Office Action dated Mar. 16, 2011.
U.S. Appl. No. 11/096,287, filed Mar. 31, 2005 Final Office Action dated Oct. 26, 2009.
U.S. Appl. No. 11/096,287, filed Mar. 31, 2005 Non-Final Office Action dated Feb. 12, 2009.
U.S. Appl. No. 11/096,287, filed Mar. 31, 2005 Non-Final Office Action dated Jan. 16, 2013.
U.S. Appl. No. 11/096,287, filed Mar. 31, 2005 Non-Final Office Action dated Sep. 29, 2010.
U.S. Appl. No. 11/096,287, filed Mar. 31, 2005 Non-Final Office Action dated Sep. 5, 2008.
U.S. Appl. No. 13/931,633, filed Jun. 28, 2013 Non-Final Office Action dated Jun. 8, 2015.
U.S. Appl. No. 13/931,633, filed Jun. 28, 2013 Notice of Allowance dated Dec. 23, 2015.
U.S. Appl. No. 14/012,945, filed Aug. 28, 2013 Non-Final Office Action dated Nov. 6, 2013.
U.S. Appl. No. 15/167,645, filed May 27, 2016 Non-Final Office Action dated Aug. 18, 2016.
U.S. Appl. No. 15/167,645, filed May 27, 2016 Notice of Allowance dated Jan. 17, 2017.
U.S. Appl. No. 15/225,669, filed Aug. 1, 2016 Advisory Action dated Aug. 31, 2018.
U.S. Appl. No. 15/225,669, filed Aug. 1, 2016 Advisory Action dated Sep. 13, 2017.
U.S. Appl. No. 15/225,669, filed Aug. 1, 2016 Final Office Action dated Apr. 24, 2017.
U.S. Appl. No. 15/225,669, filed Aug. 1, 2016 Final Office Action dated Jun. 3, 2019.
U.S. Appl. No. 15/225,669, filed Aug. 1, 2016 Final Office Action dated Jun. 5, 2018.
U.S. Appl. No. 15/225,669, filed Aug. 1, 2016 Non-Final Office Action dated Nov. 17, 2017.
U.S. Appl. No. 15/225,669, filed Aug. 1, 2016 Non-Final Office Action dated Nov. 30, 2018.
U.S. Appl. No. 15/225,669, filed Aug. 1, 2016 Non-Final Office Action dated Oct. 19, 2016.
U.S. Appl. No. 15/225,669, filed Aug. 1, 2016 Notice of Allowance dated Oct. 2, 2019.
U.S. Pat. No. 8,171,553 filed Apr. 20, 2006, Inter Parties Review Decision dated Jul. 10, 2015.
U.S. Pat. No. 8,291,499 filed Mar. 16, 2012, Inter Parties Review Decision dated Jul. 10, 2015.
Venezia, Paul , “NetDetector Captures Intrusions”, InfoWorld Issue 27, (“Venezia”), (Jul. 14, 2003).
Vladimir Getov: “Security as a Service in Smart Clouds—Opportunities and Concerns”, Computer Software and Applications Conference (COMPSAC), 2012 IEEE 36th Annual, IEEE, Jul. 16, 2012 (Jul. 16, 2012).
Wahid et al., Characterising the Evolution in Scanning Activity of Suspicious Hosts, Oct. 2009, Third International Conference on Network and System Security, pp. 344-350.
Whyte, et al., “DNS-Based Detection of Scanning Works in an Enterprise Network”, Proceedings of the 12th Annual Network and Distributed System Security Symposium, (Feb. 2005), 15 pages.
Williamson, Matthew M., “Throttling Viruses: Restricting Propagation to Defeat Malicious Mobile Code”, ACSAC Conference, Las Vegas, NV, USA, (Dec. 2002), pp. 1-9.
Yuhei Kawakoya et al: “Memory behavior-based automatic malware unpacking in stealth debugging environment”, Malicious and Unwanted Software (Malware), 2010 5th International Conference on, IEEE, Piscataway, NJ, USA, Oct. 19, 2010, pp. 39-46, XP031833827, ISBN:978-1-4244-8-9353-1.
Zhang et al., The Effects of Threading, Infection Time, and Multiple-Attacker Collaboration on Malware Propagation, Sep. 2009, IEEE 28th International Symposium on Reliable Distributed Systems, pp. 73-82.
“Mining Specification of Malicious Behavior”—Jha et al., UCSB, Sep. 2007 https://www.cs.ucsb.edu/.about.chris/research/doc/esec07.sub.—mining.pdf-.
“Network Security: NetDetector—Network Intrusion Forensic System (NIFS) Whitepaper”, (“NetDetector Whitepaper”), (2003).
“Packet”, Microsoft Computer Dictionary, Microsoft Press, (Mar. 2002), 1 page.
“When Virtual is Better Than Real”, IEEEXplore Digital Library, available at, http://ieeexplore.ieee.org/xpl/articleDetails.iso?reload=true&arnumber=990073, (Dec. 7, 2013).
Abdullah, et al., Visualizing Network Data for Intrusion Detection, 2005 IEEE Workshop on Information Assurance and Security, pp. 100-108.
Adetoye, Adedayo, et al., “Network Intrusion Detection & Response System”, (“Adetoye”) (Sep. 2003).
AltaVista Advanced Search Results. “attack vector identifier”. Http://www.altavista.com/web/results?ltag=ody&pg=aq&aqmode=aqa=Event+Orch- estrator . . . , (Accessed on Sep. 15, 2009).
AltaVista Advanced Search Results. “Event Orchestrator”. Http://www.altavista.com/web/results?ltag=ody&pg=aq&aqmode=aqa=Event+Orch- esrator . . . , (Accessed on Sep. 3, 2009).
Apostolopoulos, George; hassapis, Constantinos; “V-eM: A cluster of Virtual Machines for Robust, Detailed, and High-Performance Network Emulation”, 14th IEEE International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems, Sep. 11-14, 2006, pp. 117-126.
Aura, Tuomas, “Scanning electronic documents for personally identifiable information”, Proceedings of the 5th ACM workshop on Privacy in electronic society. ACM, 2006.
Baecher, “The Nepenthes Platform: An Efficient Approach to collect Malware”, Springer-verlaq Berlin Heidelberg, (2006), pp. 165-184.
Baldi, Mario; Risso, Fulvio; “A Framework for Rapid Development and Portable Execution of Packet-Handling Applications”, 5th IEEE International Symposium Processing and Information Technology, Dec. 21, 2005, pp. 233-238.
Bayer, et al., “Dynamic Analysis of Malicious Code”, J Comput Virol, Springer-Verlag, France., (2006), pp. 67-77.
Boubalos, Chris , “extracting syslog data out of raw pcap dumps, seclists.org, Honeypots mailing list archives”, available at http://seclists.org/honeypots/2003/q2/319 (“Boubalos”), (Jun. 5, 2003).
Chaudet, C., et al., “Optimal Positioning of Active and Passive Monitoring Devices”, International Conference on Emerging Networking Experiments and Technologies, Proceedings of the 2005 ACM Conference on Emerging Network Experiment and Technology, CoNEXT '05, Toulousse, France, (Oct. 2005), pp. 71-82.
Chen, P. M. and Noble, B. D., “When Virtual is Better Than Real, Department of Electrical Engineering and Computer Science”, University of Michigan (“Chen”) 2001.
Cisco “Intrusion Prevention for the Cisco ASA 5500-x Series” Data Sheet (2012).
Cisco, Configuring the Catalyst Switched Port Analyzer (SPAN) (“Cisco”), (1992).
Clark, John, Sylvian Leblanc,and Scott Knight. “Risks associated with usb hardware trojan devices used by insiders.” Systems Conference (SysCon), 2011 IEEE International. IEEE, 2011.
Cohen, M.I. , “PyFlag—An advanced network forensic framework”, Digital investigation 5, Elsevier, (2008), pp. S112-S120.
Costa, M., et al., “Vigilante: End-to-End Containment of Internet Worms”, SOSP '05, Association for Computing Machinery, Inc., Brighton U.K., (Oct. 23-26, 2005).
Crandall, J.R. , et al., “Minos:Control Data Attack Prevention Orthogonal to Memory Model”, 37th International Symposium on Microarchitecture, Portland, Oregon, (Dec. 2004).
Deutsch, P. , “Zlib compressed data format specification version 3.3” RFC 1950, (1996).
Didier Stevens, “Malicious PDF Documents Explained”, Security & Privacy, IEEE, IEEE Service Center, Los Alamitos, CA, US, vol. 9, No. 1, Jan. 1, 2011, pp. 80-82, XP011329453, ISSN: 1540-7993, DOI: 10.1109/MSP.2011.14.
Distler, “Malware Analysis: An Introduction”, SANS Institute InfoSec Reading Room, SANS Institute, (2007).
Dunlap, George W. , et al., “ReVirt: Enabling Intrusion Analysis through Virtual-Machine Logging and Replay”, Proceeding of the 5th Symposium on Operating Systems Design and Implementation, USENIX Association, (“Dunlap”), (Dec. 9, 2002).
Excerpt regarding First Printing Date for Merike Kaeo, Designing Network Security (“Kaeo”), (2005).
Filiol, Eric, et al., “Combinatorial Optimisation of Worm Propagation on an Unknown Network”, International Journal of Computer Science 2.2 (2007).
FireEye Malware Analysis & Exchange Network, Malware Protection System, FireEye Inc., 2010.
FireEye Malware Analysis, Modern Malware Forensics, FireEye Inc., 2010.
FireEye v.6.0 Security Target, pp. 1-35, Version 1.1, FireEye Inc., May 2011.
Gibler, Clint, et al. AndroidLeaks: automatically detecting potential privacy leaks in android applications on a large scale. Springer Berlin Heidelberg, 2012.
Goel, et al., Reconstructing System State for Intrusion Analysis, Apr. 2008 SIGOPS Operating Systems Review, vol. 42 Issue 3, pp. 21-28.
Gregg Keizer: “Microsoft's HoneyMonkeys Show Patching Windows Works”, Aug. 8, 2005, XP055143386, Retrieved from the Internet: URL:http://www.informationweek.com/microsofts-honeymonkeys-show-patching-windows-works/d/d-d/1035069? [retrieved on Jun. 1, 2016].
Heng Yin et al., Panorama: Capturing System-Wide Information Flow for Malware Detection and Analysis, Research Showcase @ CMU, Carnegie Mellon University, 2007.
Hiroshi Shinotsuka, Malware Authors Using New Techniques to Evade Automated Threat Analysis Systems, Oct. 26, 2012, http://www.symantec.com/connect/blogs/, pp. 1-4.
Hjelmvik, Erik , “Passive Network Security Analysis with NetworkMiner”, (IN)Secure, Issue 18, (Oct. 2008), pp. 1-100.
Idika et al., A-Survey-of-Malware-Detection-Techniques, Feb. 2, 2007, Department of Computer Science, Purdue University.
IEEE Xplore Digital Library Sear Results for “detection of unknown computer worms”. Http//ieeexplore.ieee.org/searchresult.jsp?SortField=Score&SortOrder=desc-&ResultC . . . , (Accessed on Aug. 28, 2009).
Isohara, Takamasa, Keisuke Takemori, and Ayumu Kubota. “Kernel-based behavior analysis for android malware detection.” Computational intelligence and Security (CIS), 2011 Seventh International Conference on. IEEE, 2011.
Kaeo, Merike , “Designing Network Security”, (“Kaeo”), (Nov. 2003).
Kevin A Roundy et al: “Hybrid Analysis and Control of Malware”, Sep. 15, 2010, Recent Advances in Intrusion Detection, Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 317-338, XP019150454 ISBN:978-3-642-15511-6.
Khaled Salah et al: “Using Cloud Computing to Implement a Security Overlay Network”, Security & Privacy, IEEE, IEEE Service Center, Los Alamitos, CA, US, vol. 11, No. 1, Jan. 1, 2013 (Jan. 1, 2013).
Kim, H. , et al., “Autograph: Toward Automated, Distributed Worm Signature Detection”, Proceedings of the 13th Usenix Security Symposium (Security 2004), San Diego, (Aug. 2004), pp. 271-286.
King, Samuel T., et al., “Operating System Support for Virtual Machines”, (“King”) (2003).
Krasnyansky, Max , et al., Universal TUN/TAP driver, available at https://www.kernel.org/doc/Documentation/networking/tuntap.txt (2002) (“Krasnyansky”).
Kreibich, C. , et al., “Honeycomb-Creating Intrusion Detection Signatures Using Honeypots”, 2nd Workshop on Hot Topics in Networks (HotNets-11), Boston, USA, (2003).
Kristoff, J. , “Botnets, Detection and Mitigation: DNS-Based Techniques”, NU Security Day, (2005), 23 pages.
Lastline Labs, The Threat of Evasive Malware, Feb. 25, 2013, Lastline Labs, pp. 1-8.
Leading Colleges Select FireEye to Stop Malware-Related Data Breaches, FireEye Inc., 2009.
Provisional Applications (1)
Number Date Country
60559198 Apr 2004 US
Continuations (4)
Number Date Country
Parent 15225669 Aug 2016 US
Child 16791933 US
Parent 15167645 May 2016 US
Child 15225669 US
Parent 13931633 Jun 2013 US
Child 15167645 US
Parent 11096287 Mar 2005 US
Child 13931633 US