1. Field of the Invention
The invention relates generally to computer security and more particularly to detecting malicious software operating in computers and other digital devices.
2. Related Art
Malicious software, or malware for short, may include any program or file that is harmful by design to a computer. Malware includes computer viruses, worms, Trojan horses, adware, spyware, and any programming that gathers information about a computer or its user or otherwise operates without permission. Owners of the computers are often unaware that these programs have been added to their computers and are often similarly unaware of their function.
Malicious network content is a type of malware distributed over a network via websites, e.g., servers operating on a network according to Hypertext Transfer Protocol (“HTTP”) or other well-known standard. Malicious network content distributed in this manner may be actively downloaded and installed on a computer, without the approval or knowledge of its user, simply by the computer accessing the website hosting the malicious network content (the “malicious website”). Malicious network content may be embedded within objects associated with web pages hosted by the malicious website. Malicious network content may also enter a computer on receipt or opening of email. For example, email may contain an attachment, such as a PDF document, with embedded malicious executable programs. Furthermore, malicious content may exist in files contained in a computer memory or storage device, having infected those files through any of a variety of attack vectors.
Various processes and devices have been employed to prevent the problems associated with malicious content. For example, computers often run antivirus scanning software that scans a particular computer for viruses and other forms of malware. The scanning typically involves automatic detection of a match between content stored on the computer (or attached media) and a library or database of signatures of known malware. The scanning may be initiated manually or based on a schedule specified by a user or system administrator associated with the particular computer. Unfortunately, by the time malware is detected by the scanning software, some damage on the computer or loss of privacy may have already occurred, and the malware may have propagated from the infected computer to other computers. Additionally, it may take days or weeks for new signatures to be manually created, the scanning signature library updated and received for use by the scanning software, and the new signatures employed in new scans.
Moreover, anti-virus scanning utilities may have limited effectiveness to protect against all exploits by polymorphic malware. Polymorphic malware has the capability to mutate to defeat the signature match process while keeping its original malicious capabilities intact. Signatures generated to identify one form of a polymorphic virus may not match against a mutated form. Thus polymorphic malware is often referred to as a family of virus rather than a single virus, and improved antivirus techniques to identify such malware families is desirable.
Another type of malware detection solution employs virtual environments to replay content within a sandbox established by virtual machines (VMs) that simulates a target operating environment. Such solutions monitor the behavior of content during execution to detect anomalies and other activity that may signal the presence of malware. One such system sold by FireEye, Inc., the assignee of the present patent application, employs a two-phase malware detection approach to detect malware contained in network traffic monitored in real-time. In a first or “static” phase, a heuristic is applied to network traffic to identify and filter packets that appear suspicious in that they exhibit characteristics associated with malware. In a second or “dynamic” phase, the suspicious packets (and typically only the suspicious packets) are replayed within one or more virtual machines. For example, if a user is trying to download a file over a network, the file is extracted from the network traffic and analyzed in the virtual machine using an instance of a browser to load the suspicious packets. The results of the analysis constitute monitored behaviors of the suspicious packets, which may indicate that the file should be classified as malicious. The two-phase malware detection solution may detect numerous types of malware, and even malware missed by other commercially available approaches. The two-phase malware detection solution may also achieve a significant reduction of false positives relative to such other commercially available approaches. Otherwise, dealing with a large number of false positives in malware detection may needlessly slow or interfere with download of network content or receipt of email, for example. This two-phase approach has even proven successful against many types of polymorphic malware and other forms of advanced persistent threats.
In some instances, malware may take the form of a bootkit, also known as a kernel rootkit. As used herein, the term ‘bootkit’ refers to malicious code that installs itself in a boot record of the kernel of an operating system of a compromised computer without the knowledge or authority of the infected computer's user. The infected boot record may be the master boot record, partition boot record, boot loader, or volume boot record. A bootkit may actively hide its presence from administrators by subverting standard operating system functionality. Moreover, a bootkit is inherently hard to detect because it may be executed before the operating system and may subvert operating system functionality to hide its presence. For example, bootkits may be able to hook and bypass operating system routines, initialization (processor mode switch), and security checks (integrity, code-signed, etc.). Bootkits may create a hidden file system within the infected computer, in which it can hide other malware and/or copies of infected files.
Generally speaking, a bootkit functions at a fundamental level of operation of a computer, associated with the kernel of its operating system. Known operating systems communicate with an external device such as a disk controller, peripheral device and other hardware through the use of an electronic signal called an interrupt. For example, when an application sends a system call seeking to read or write to a hard disk, it issues an interrupt. Then, an interrupt handler function of the operating system normally handles and completes the interrupt. A bootkit installed in the operating system may hook (intercept) the interrupt and/or related kernel functions in order to modify the way the interrupt is handled. The bootkit may place an internal address in the system service descriptor table (SSDT) of a Windows® operating system or the system call table (SCT) of a Linux® operating system in order to handle an interrupt itself instead of the original handler. Indeed, a bootkit may modify data structures in a Windows' kernel using a method known as direct kernel object modification (DKOM). This can permit the bootkit to rewrite a portion of code of the operating system, for example, when the kernel loads to handle the interrupt. The rewritten code may allow the bootkit to bypass or modify integrity testing and other security protection mechanisms, and even bypass advanced operating protection systems, such as patch guard, and thereby remain concealed. Even full disk encryption is to no avail in protecting a compromised computer since, even if all other data on a boot-up drive is encrypted, the boot sequence located in the master boot record typically cannot be encrypted.
It has been suggested that a defense against bootkit attacks is the prevention of unauthorized physical access to the system, but this is impractical in today's networked world. Moreover, virus scanning and next generation firewall technology have not prevented advanced forms of bootkits from gaining access to operating system kernels. Recently, operating systems themselves have incorporated counter-measures to thwart the threat of bootkits. For example, 64-bit versions of Microsoft Windows implement mandatory signing of all kernel-level drivers in order to make it more difficult for untrusted code to execute with the highest privileges in a computer, and implement kernel patch protection. However, bootkits are also rapidly evolving to circumvent such counter-measures.
Further enhancement to malware detection effectiveness is desirable of course, particularly as malware developers continue to create new forms of exploits, including more sophisticated bootkits, which can have potentially serious impact on computer and network infrastructure.
The invention will be more fully understood with reference to the following detailed description in conjunction with the drawings, of which:
Introduction
Generally speaking, a bootkit is a type of (or part of) an active infiltration attack, often operating in a two-step process. The first step is infection, which may take the form of a typically small package of malicious code (malware) being injected into a computer, whose function is to compromise the infected device. The second step involves the resident bootkit performing malicious activity. Embodiments of the invention are designed to detect certain types of malicious activity of bootkits. As used herein a “computer” is any electronic device having a processor for running an operating system, which may include, without limitation, notebook computers, desktop computers, tablets, smart phones and other smart devices and equipment, and often employs a network interface for communication over a network, such as, for example, the Internet. The terms “computer” and “computer systems” may be construed as synonymous as used throughout this specification, unless context demands otherwise.
Embodiments of the invention detect bootkits resident on a computer by detecting a change or attempted change to contents of boot locations of persistent storage, where any detected change or attempted change represents evidence of a resident bootkit and in response, an alert regarding the evidence of a resident bootkit may be issued. Some embodiments may monitor computer operations seeking to change the content of boot locations of persistent storage, where the monitored operations may include API calls performing, for example, WRITE, READ or APPEND operations with respect to the contents of the boot locations. Other embodiments may generate a baseline hash of the contents of the boot locations at a first point of time and a hash snapshot of the boot locations at a second point of time, and compare the baseline hash and hash snapshot where any difference between the two hash values constitutes evidence of a resident bootkit. Yet other embodiments may perform bootkit detection using both techniques to better assure detection of bootkits.
As used herein, boot locations are areas (e.g., addressable locations) of persistent storage that store contents (including executable code and data) required to load an operating system for execution in any execution environment, including a virtual execution environment as provided by a virtual machine. These shall sometimes be referred to as the “boot locations” and the “boot content.” The boot locations may store the master boot record. In some embodiments, the boot locations may store a master boot record (“MBR”) and one or more volume boot records (“VBRs”). Some embodiments monitor any changes or attempted changes to only the boot locations containing the MBR, and others monitor any changes or attempted changes to both the MBR and one or more of the VBR.
Embodiments of the invention may perform an integrity check of boot content to detect bootkit activity. An integrity checker initially generates and stores, preferably in persistent storage, a baseline hash of the record. Thereafter, the integrity checker generates one or more additional hashes of the MBR taken over time. The hash baseline is used as a basis or standard for comparison with each subsequent hash instance, called the hash snapshot. Where plural snapshots are taken, they may be generated on a periodic or aperiodic basis. The integrity checker compares the hash baseline with each hash snapshot. The boot content is not expected to change during normal operation of a computer. Any detected difference in the hash values is indicative of abnormal activity and thus of a resident bootkit. The reason this inference can be made is that few legitimate applications change the boot content. Moreover, these applications are not typically used by ordinary users found in a commercial environment. On the other hand, malicious bootkits frequently make changes to the boot content. Accordingly, the integrity checker may generate a bootkit alert if any difference is detected, and may report the details of the malware attack to an administrator or user.
The proposed techniques may be implemented to detect bootkits in computers in use, for example, within enterprises, by performing the methods described herein (or select steps thereof), for example, as background processes during normal computer operation as part of an on-going malware detection/protection program. Where only select steps are performed during normal operation of the computers, the remaining steps may be performed by a security station, which may issue an alert to IT or security personnel. Accordingly, the proposed techniques may be implemented in network endpoints and standalone computers, for example, by incorporation of bootkit detection agents into their respective operating systems or into utilities or other computer programs installed thereon.
In alternative embodiments, the proposed techniques may be implemented in a bootkit detection appliance or malware detection system, which may detect changes or attempted changes caused by samples (e.g., files or network content, for example) that may be malicious and contain bootkit code. They may also be implemented in the two-phase malware detection solutions, as described above, or in other malware detection systems, with or without virtual execution environments. As such, the invention may be deployed to protect computer systems in an enterprise environment or to test known or unknown samples in diagnostic or forensic labs.
For a computer running a virtual machine, embodiments may implement the invention partially within a guest image under the control of a hypervisor or VMM, and partially within the virtual machine itself. Additionally, embodiments may implement the invention partially within the virtual machine and its guest image, and partially within an external security station or malware detection system.
Bootkit Detection System Architecture and Operation
As noted, in order to be readily locatable, the MBR is always the first sector of the drive, though the precise format and structure of the boot record depends on the operating system type and version. Sometimes the term MBR is used to describe the first sector of a bootable disk, and, at other times, it refers to the boot content contained therein, and sometimes it is referred to as the master boot block or master partition boot sector. Normally, IBM Personal Computers use 512-byte sectors, real or emulated, and the MBR is thus up to 512 bytes in length.
Where an operating system is to be loaded within a virtual machine, a virtual bootable disk or other persistent storage is typically used rather than a physical disk. Nonetheless, the principles just discussed apply: the MBR may be located within sector 0 of the virtual disk, and, upon the disk being mounted, sector 0 of the virtual bootable disk can be read, its partition table accessed to identify, for example, the locations of the VBRs, and its boot code executed. The same is true of flash drives, which typically have analogous formats to typical SCSI disk drives, and thus its MBR and partition table may be found in its sector 0.
During operation, after a computer is powered on, its basic input/output system (BIOS) typically performs a power-on self test (POST) and initializes the system. Next, the BIOS copies the first sector of a bootable drive containing the MBR into memory and passes control of the computer to the boot code (executable instructions) contained therein. Execution of the boot code accesses the partition table, which tells the computer how the hard drive is partitioned, and how to load the operating system. In other words, the boot code uses the partition table to identify a configured bootable partition on the drive, which permits the system to load and execute its VBRs.
Processor 202 is coupled via transmission medium 208 to a persistent storage 210. Persistent storage 210 includes a bootable disk 211, which permits processor 202 to boot up, as described above. Persistent storage 210 also includes an operating system 212 and a bootkit detector 212, both of which may take the form of executable computer program code. The processor 202 may execute the operating system 212 natively, and the bootkit detector 214 may run as an application over the operating system 212. For purposes of the following discussion, we will refer to the MBR as an illustrative example of the boot content, though this should not be construed as limiting the boot content to only the MBR unless otherwise indicated. The bootkit detector 212 may include an MBR extraction logic 218, which is configured to access the master record from a bootable disk (e.g., a virtual disk) to extract the MBR therefrom (and possibly other sectors, depending on the embodiment, though the embodiment will be discussed in terms of the MBR); a generation logic 220, which is configured to generate an MBR-based hash signature and store it in a hash log or database 222; a hash comparison logic 224, which is configured to compare a first or baseline hash signature with a second or snapshot hash signature; and an alert logic 226, which is configured to issue an alert if the comparison logic 224 determines that the MBR has been changed in that it finds a difference between the hash values of the baseline and snapshot signatures. In some embodiments, the bootkit detector 214 may execute potentially malicious samples within a virtualization environment 228 having a guest operating system 229, and possibly a computer application, such as, for example, a browser or email application (not shown), running within a virtual machine 230. During execution, the processor 202 may execute an operating system instance 229 within an instance of the virtual machine 228, which runs over the operating system 212.
In step 308, logic obtains, loads, and executes a sample within a virtual environment to be tested to determine whether the sample contains a malicious bootkit. Where the sample is executable code it may be run as a computer program or application over the guest image of the operating system in the virtual environment. Where the sample constitutes an object (such as a PDF document), which is itself not executable even though it may contain embedded executables, the sample may be loaded by a suitable computer program or application (such as, in this example, a PDF reader) running over the guest operating system and together constituting a guest image executed by a virtual machine.
Next, in step 316, logic determines whether execution of the sample has finished. If it has not, then, in step 314, method 300 waits a predetermined or dynamically set period of time (where dynamically set, e.g., based on experience in executing such samples within the guest image), before repeating step 316. When the logic of step 316 determines that execution has finished, in step 318, logic reads one on more boot record sectors from the bootable disk, and, for example, the same MBR-containing sector(s) as read to generate the baseline hash signature (H2). In step 322, logic generates a hash snapshot based on the read boot content, in this example, the MBR, at a point of time (t2), which together with baseline signature H1, will serve as a basis for comparison of the MBR over time (t1 to t2). In some embodiments, snapshot hashes may be taken from time to time during the execution of the sample. In step 324, logic determines whether the baseline hash signature is the same as the snapshot hash signature. It may perform this comparison simply by subtracting one hash value from the other. If the difference is any value other than zero, then H1 is not equal to H2. This result would indicate that the MBR has been changed at some point in time between the generation of the baseline hash and the snapshot hash (that is, between t1 and t2). This, in turn, would indicate that a mechanism must have caused that change in the MBR, and that mechanism may very well be a bootkit. If the baseline hash is equal to the snapshot hash, in step 326, logic may be employed to reset the virtual environment to ready it for a next sample to be tested. As such, the method 300 may return to step 308. On the other hand, if the baseline hash is not equal to the snapshot hash, in step 328, logic classifies the sample as malicious, that is to say, as likely (that is, having a high probability of) containing a bootkit.
Controller 402 may be implemented as part of a VM monitor or manager (VMM), also referred to as a hypervisor for managing or monitoring VMs. The controller 402 may execute an operating system instance 433 of host operating system (OS) 444, which is stored in storage device 406. VM 404 may host a guest OS, depicted as operating system instance 410, which is different from the host OS 433 of the controller 402. The host OS 433 and the guest OS 410 may be the same type of operating systems or different types of operating systems (e.g., Windows™, Linux™, Unix™, Mac OS™, iOS™, etc.) or different versions thereof. A VM is a simulation of a computer (abstract or real) that is usually different from the target computer (where it is being simulated on). Virtual machines may be based on specifications of a hypothetical computer or emulate a computer architecture and functions of a real world computer. A virtual machine referred to herein can be any type of virtual machines, such as, for example, hardware emulation, full virtualization, para-virtualization, and operating system-level virtualization virtual machines.
On initial execution of the virtual machine 404, a processor or processors (not shown in this figure) of the controller 402 accesses a virtual disk 408 provided by the virtual machine 404 to obtain one or more sectors of a boot record 412, preferably the sector(s) containing the boot content, as stored thereon. It should be noted that boot record 412 is isolated from the boot record 446 associated with operating system 444. A hash generator 426 included in the controller 402, generates a hash of boot content obtained by the controller 402 from the virtual disk 408, and, for example, a hash of the MBR. That hash is the baseline hash serving as the baseline signature of the MBR for later testing of content samples, including the content sample 414, by the malicious content detection system 400. The baseline hash signature may be stored in the event log 432. In some embodiments, the baseline hash signature may be stored as a heavily obfuscated value under kernel software protection.
According to one embodiment, when a content sample 406 to be tested as to whether it may contain a bootkit is received for a dynamic content analysis (as opposed to be a static content analysis described below), a scheduler 424 of controller 402 is configured to identify and select a VM, in this example VM 404, from a VM pool 450 that has been configured to closely simulate a target operating environment (e.g., particular version of an OS with particular versions of certain software installed therein) in which the content sample 414 is to be analyzed. The scheduler 424 then launches VM 404 in which monitoring module 416 is running and configured to monitor activities and behavior of content sample 414. In addition, monitoring module 416 maintains a persistent communication channel with analysis module 428 of controller 402 to communicate certain events or activities of content sample 414 during the execution.
After the content sample 414 is executed, or at one or more times during its execution depending on the embodiment, the monitoring module 416 may trigger the generation by the hash generator 426 of a new hash value for the boot content, that is, the same content involved in the baseline hash, for example, the MBR of the boot record 412, each new hash value constituting a hash snapshot signature. Each hash snapshot signature may be stored in the event log 432. Monitoring module 416 is configured to send a message via the communication channel to analysis module 428 to indicate completion of execution of the content sample 414.
In response to the generation of each hash snapshot signature, or during a designated analysis phase after the generation of one or more hash snapshot signatures for the content sample 414, the analysis module 428 may compare the baseline hash signature with the one or more snapshot signatures. Any difference between the baseline signature and any of the snapshot signatures is considered an indicator of a bootkit being contained in the content sample 414. As a result, the analysis module 428 generates a message indicative of the presence of the bootkit, which may also contain information regarding any other behavior detected by the monitoring module 416 during execution of the content sample 414 that constitutes an anomaly relative to normal behavior during execution and thus would be indicative of other malicious activity by the content sample 414. The message is sent to the event log 432, which records the message contents as an event triggered by content sample 414. Event log 432 records events that have been selectively monitored and detected by monitoring module 416. Content of the event log 432 may be stored in a persistent storage as part of event log file(s) 448 of VM disk file 442 associated with VM 404. The recorded events may be analyzed by analysis module 428 based on a set of rules or policies (not shown) to determine whether content sample 414 is likely malicious (e.g., high probability of malicious) and/or should be declared as malicious. In the event that the content sample 414 is found to be malicious, that is, that it contains at least a bootkit (if not also other malware, depending on the detected anomalous activities), the content sample 414 may be stored in the malicious content files 4490 the VM disk file 442. In addition, and alert generator 434 may issue an alert so that a user or administrator may take appropriate steps in light of the malicious content being discovered.
Now, an alternative embodiment of the invention will be described involving detecting bootkits, for example, on network endpoints.
The I/O interface 510 of host computer system 502 may be connected (by cable or wireless connection) to standard devices, such as one or more input devices 516 (e.g., a keyboard, a mouse), output devices 518 (e.g., a display device, a printer), and as well as, one or more standard input/output (I/O) devices 524 (e.g., touch screen, a USB memory device, compact disk (CD) or DVD drive), storage devices 520, and other peripheral devices 522, and, all of which may be operable via device drivers installed in the operating system 504.
The I/O interface 510 of host computer system 502 is also coupled by the network 526 to a server system 530 of client-server system 500. Network 526 may be any network or network system, including a proprietary network and the Internet, or combinations thereof. Server system 530 may includes a processor 534, a persistent storage 536, and a network interface 538. Due to that connection between the host computer system 502 and the network 526, the host computer system 502 may be regarded as a network endpoint, to which and from which network communications are sent.
Further, host computer system 502 is also coupled by network 526 to a computer system 528, such as an attacker computer system, of client-server system 500. The attacker computer system 528 may have injected a bootkit into the host computer system 502. In one embodiment, computer system 528 is similar to host computer system 502 and, for example, including a central processing unit, an input output (I/O) interface, a persistent storage and one or more of the other devices described above, or may be configured as a server computer system similar to server computer system 530. The various hardware components of computer system 528 are not illustrated to avoid detracting from the principals of the invention. The particular type and configuration of host computer system 502, computer system 528, and server system 530 are not essential to the present invention.
In one embodiment of the invention, the bootkit detection agent 506 is stored in memory 512 of host computer system 502 and executed on host computer system 502, as a utility or computer application that runs over operating system 504, as illustrated. In another embodiment, the bootkit detection system 506 may be implemented within the operating system 504, for example, as a bootkit detection module. Of course, the operating system may incorporate only some of the aspects of the bootkit detection system, such as one or more of an MBR reader, hash generator, hash comparator, and/or alert generator, to name a few. Noteworthy, these embodiments need not employ a virtual environment, but rather test for bootkit activity during normal execution of the operating system, utility or computer application within a computer system.
One embodiment of the invention takes advantage of “software as a service” (“SaaS”) principles of business, in which a bootkit detection system may be a cloud-based server providing services to one or more service subscribers. In this environment, the computers under test are located at one or more clients that avail themselves of the services of the bootkit detection system located, for example, within the Internet or within a proprietary network. In some embodiments, the services of the bootkit detection system may be provided by an IT service provider on behalf of a number of customers that subscribe to its services, each of which having at least one computer either located on the customer's premised or coupled to the customer's trusted network and which is to be tested for bootkits. The cloud-based bootkit detection system may use an agent installed on an endpoint, as shown and described in
Controller Architecture
The controller 700 may also have a communication network interface 740, an input/output (I/O) interface 750, and a user interface 760. The communication network interface 740 may be coupled with a communication network 772 via a communication medium 770. The communications network interface 740 may communicate with other digital devices (not shown) via the communications medium 770. The communication interface 740 may include a network tap 840 (
The I/O interface 750 may include any device that can receive input from or provide output to a user. The I/O interface 750 may include, but is not limited to, a flash drive, a compact disc (CD) drive, a digital versatile disc (DVD) drive, or other type of I/O peripheral (not separately shown). The user interface 760 may include, but is not limited to a keyboard, mouse, touch screen, keypad, biosensor, display monitor or other human-machine interface (not separately shown) to allow a user to control the controller 700. The display monitor may include a screen on which is provided a command line interface or graphical user interface.
In various embodiments of the invention, a number of different controllers (for example, each of a type as illustrated and described for controller 700 may be used to implement various components of embodiments of the invention.
Computer Network System with Malicious Content Detection System
Network content is an example of content for malicious content detection purposes; however, other types of content can also be applied. Network content may include any data transmitted over a network (i.e., network data). Network data may include text, software, images, audio, or other digital data. An example of network content includes web content, or any network data that may be transmitted using a Hypertext Transfer Protocol (HTTP), HyperText Markup Language (HTML) protocol, or be transmitted in a manner suitable for display on a Web browser software application. Another example of network content includes email messages, which may be transmitted using an email protocol such as Simple Mail Transfer Protocol (SMTP), Post Office Protocol version 3 (POP3), or Internet Message Access Protocol (IMAP4). A further example of network content includes Instant Messages, which may be transmitted using an Instant Messaging protocol such as Session Initiation Protocol (SIP) or Extensible Messaging and Presence Protocol (XMPP). In addition, network content may include any network data that is transferred using other data transfer protocols, such as File Transfer Protocol (FTP).
The malicious network content detection system 850 may monitor exchanges of network content (e.g., Web content) in real-time rather than intercepting and holding the network content until such time as it can determine whether the network content includes malicious network content. The malicious network content detection system 850 may be configured to inspect exchanges of network content over the communication network 828, identify suspicious network content, and analyze the suspicious network content using a virtual machine to detect malicious network content. The communication network 820 may include a public computer network such as the Internet, in which case a firewall 825 may be interposed between the communication network 820 and the client device 830. Alternatively, the communication network may be a private computer network such as a wireless telecommunication network, wide area network, or local area network, or a combination of networks. Though the communication network 820 may include any type of network and be used to communicate different types of data, communications of Web data will be discussed below for purposes of example.
The malicious network content detection system 850 is shown as coupled with the network 820 by a network tap 840 (e.g., a data/packet capturing device). The network tap 840 may include a digital network tap configured to monitor network data and provide a copy of the network data to the malicious network content detection system 850. Network data may comprise signals and data that are transmitted over the communication network 820. The network tap 840 may copy any portion of the network data, for example, any number of data packets from the network data. In embodiments where the malicious content detection system 850 is implemented as an dedicated appliance or a dedicated computer system, the network tap 840 may include an assembly integrated into the appliance or computer system that includes network ports, network interface card and related logic (not shown) for connecting to the communication network 820 to non-disruptively “tap” traffic thereon and provide a copy of the traffic to the heuristic module 860. In other embodiments, the network tap 840 can be integrated into a firewall (e.g., using SCAN ports), router, switch or other network device (not shown) or can be a standalone component, such as an appropriate commercially available network tap. In virtual environments, a virtual tap (vTAP) can be used to copy traffic from virtual networks. The network tap 840 may also capture metadata from the network data. The metadata may be associated with the server device 810 and/or the client device 830. For example, the metadata may identify the server device 810 and/or the client device 830. In some embodiments, the server device 810 transmits metadata which is captured by the tap 815. In other embodiments, a heuristic module 860 (described herein) may analyze data packets within the network data in order to generate the metadata. The term, “content,” as used herein may be construed to include the intercepted network data and/or the metadata unless the context requires otherwise.
The malicious network content detection system 825 may include a heuristic module 860, a heuristics database 862, a scheduler 870, a virtual machine pool 880, an analysis engine 882 and a reporting module 884. The heuristic module 860 receives the copy of the network data from the network tap 840 and applies heuristics to the data to determine if the network data might contain suspicious network content. The heuristics applied by the heuristic module 860 may be based on data and/or rules stored in the heuristics database 862. The heuristic module 860 may examine the image of the captured content without executing or opening the captured content. For example, the heuristic module 860 may examine the metadata or attributes of the captured content and/or the code image (e.g., a binary image of an executable) to determine whether a certain portion of the captured content matches a predetermined pattern or signature that is associated with a particular type of malicious content. In one example, the heuristic module 860 flags network data as suspicious after applying a heuristic analysis. When a characteristic of the packet, such as a sequence of characters or keyword, is identified that meets the conditions of a heuristic, a suspicious characteristic of the network content is identified. The identified characteristic may be stored for reference and analysis. In some embodiments, the entire packet may be inspected (e.g., using deep packet inspection techniques) and multiple characteristics may be identified before proceeding to the next step. In some embodiments, the characteristic may be determined as a result of an analysis across multiple packets comprising the network content. A score related to a probability that the suspicious characteristic identified indicates malicious network content is determined.
The heuristic module 860 may also provide a priority level for the packet and/or the features present in the packet. The scheduler 870 may then load and configure a virtual machine from the virtual machine pool 870 in an order related to the priority level, and dispatch the virtual machine to the analysis engine 882 to process the suspicious network content. The heuristic module 860 may provide the packet containing the suspicious network content to the scheduler 870, along with a list of the features present in the packet and the malicious probability scores associated with each of those features. Alternatively, the heuristic module 860 may provide a pointer to the packet containing the suspicious network content to the scheduler 870 such that the scheduler 870 may access the packet via a memory shared with the heuristic module 860.
The scheduler 870 may identify the client device 830 and retrieve a virtual machine from the virtual machine pool 880 corresponding to the client device 830. A virtual machine may itself be executable software that is configured to mimic the performance of a device (e.g., the client device 830). Furthermore, the scheduler 870 may identify, for example, a Web browser running on the client device 830, and retrieve a virtual machine associated with the web browser. In some embodiments, the heuristic module 860 transmits the metadata identifying the client device 830 to the scheduler 870. In other embodiments, the scheduler 870 receives one or more data packets of the network data from the heuristic module 860 and analyzes the one or more data packets to identify the client device 830. In yet other embodiments, the metadata may be received from the network tap 840.
The scheduler 870 may retrieve and configure the virtual machine to mimic the pertinent performance characteristics of the client device 830. In one example, the scheduler 870 configures the characteristics of the virtual machine to mimic only those features of the client device 830 that are affected by the network data copied by the network tap 840. The scheduler 870 may determine the features of the client device 830 that are affected by the network data by receiving and analyzing the network data from the network tap 840. Such features of the client device 830 may include ports that are to receive the network data, select device drivers that are to respond to the network data, and any other devices coupled to or contained within the client device 830 that can respond to the network data. In other embodiments, the heuristic module 860 may determine the features of the client device 830 that are affected by the network data by receiving and analyzing the network data from the network tap 840. The heuristic module 850 may then transmit the features of the client device to the scheduler 870.
The virtual machine pool 870 may be configured to store one or more virtual machines. The virtual machine pool 870 may include software and/or a storage medium capable of storing software. In one example, the virtual machine pool 870 stores a single virtual machine that can be configured by the scheduler 870 to mimic the performance of any client device 830 on the communication network 820. The virtual machine pool 870 may store any number of distinct virtual machines that can be configured to simulate the performance of a wide variety of client devices 830.
The scheduler 870 may operate to test the network content as to whether it may contain a bootkit as well as other malware. To detect a bootkit, the scheduler 870 may cause the analysis engine 882 to perform the steps of method 300 of
The analysis engine 882 may flag the suspicious network content as malicious network content according to the observed behavior of the virtual machine. The analysis engine 882 may also generate a signature based on the malicious network content, for example, applying a hashing algorithm to the content, or a portion thereof, or using another relevant identifier. Accordingly, the analysis engine may generate a signature based on the malicious network content containing a bootkit. The reporting module 884 may issue alerts indicating the presence of malware, and, using pointers and other reference information, identify the packets of the network content containing the malware, for example, using the signatures. Additionally, the server device 810 may be added to a list of malicious network content providers, and future network transmissions originating from the server device 810 may be blocked from reaching their intended destinations, e.g., by firewall 825.
A malware probability score may be generated for each sample of network content tested. The “static” detection or analysis performed by the heuristic module 860 may generate a first score (e.g., a static detection score) according to a first scoring scheme or algorithm. The “dynamic” detection or analysis performed by the analysis engine 882 may generate a second score (e.g., a dynamic detection score) according to a second scoring scheme or algorithm. The first and second scores may be combined, according to a predetermined algorithm, to derive a final score indicating the probability that a malicious content suspect is indeed malicious or should be declared or considered with high probability of malicious.
If a bootkit is discovered in the sample, the malware content detection system 850 may obtain additional information regarding the malware infestation by permitting the malware to execute within the virtual environment, monitoring its attributes and effects. For example, the malware content detection system 850 may gather threat intelligence such as malicious domains, for example, Top Level Domains, payloads, etc.
The computer network system 800 may also include a further communication network 890, which couples the malicious content detection system (MCDS) 850 with one or more other MCDS, of which MCDS 892 and MCDS 894 are shown, and a management system 896, which may be implemented as a Web server having a Web interface. The communication network 890 may, in some embodiments, be coupled for communication with or part of network 820. The management system 896 is responsible for managing the MCDS 850, 892, 894 and providing updates to their operation systems and software programs. Also, the management system 896 may cause malware signatures generated by any of the MCDS 850, 892, 894 to be shared with one or more of the other MCDS 850, 892, 894, for example, on a subscription basis. Moreover, the malicious content detection system as described in the foregoing embodiments may be incorporated into one or more of the MCDS 850, 892, 894, or into all of them, depending on the deployment. Also, the management system 896 itself or another dedicated computer station may incorporate the malicious content detection system in deployments where such detection is to be conducted at a centralized resource.
The management system 896 may manage the detection systems 850 and 892-894 in a variety of ways. For example, an administrator may activate or deactivate certain functionalities of malicious content detection systems 850 and 892-894 or alternatively, to distribute software updates such as malicious content definition files (e.g., malicious signatures or patterns) or rules, etc. Furthermore, a user may submit via a Web interface suspicious content to be analyzed, for example, by dedicated data analysis systems 892-894. Moreover, the detection systems 850 and 892-894 may share in carrying out operations with respect to an particular sample of network content. For example, static detection (using heuristics) may be performed by detection system 850 at a client site, while dynamic detection (using a virtual machine) of the same content can be offloaded to the cloud, for example, and performed by any of the other detection systems 892-894. Moreover, in the case of bootkit detection, baseline hash and hash snapshot generation may be performed by any of the detection systems 892-894, and hash comparison can be offloaded to the cloud, for example, and performed by any of the other detection systems 892-894.
Alternative Embodiment
Referring now to
In operation, the monitoring logic 990 detects bootkit activity in various ways, depending on the embodiment. Where the samples are themselves executable programs, they may be run as program instance 984, for example, over the operating system instance 986. Where the samples are documents, such as PDF documents that may contain embedded executable objects that may, possibly contain bootkits, they may be loaded using an appropriate program, such as program instance 984. Where the samples require a particular computer application, such as a Web browser, the program instance 984 may be that browser.
During testing of the samples, the monitoring logic 990 may perform any and all of the following:
As used herein, “API calls” is a general term intended to include system calls, RPC API calls, kernel-level API calls, and user-level API calls, and may be intercepted by any known hooking techniques. By hooking these API calls, and extracting the nature of the commands contained therein and their targeted addresses within persistent storage 988, the monitoring logic 990 may be directly viewing bootkit activity.
If the monitoring logic 900 intercepts API calls or other operations of a malicious nature, the sample may be classified as containing a bootkit. If no such malicious activity is observed, the sample may be classified as clean or requiring further analysis. In some embodiments, the analysis module 428 (
It should be understood that the operations performed by the above-described illustrative embodiments are purely exemplary and imply no particular order unless explicitly required. Further, the operations may be used in any sequence when appropriate and may be partially used. Embodiments may employ various computer-implemented operations involving data stored in computer systems. These operations include physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated.
Any of the operations described herein are useful machine operations. The present invention also relates to a device or an apparatus for performing these operations. The apparatus may be specially constructed for the required purpose, or the apparatus may be a general-purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general-purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations, or multiple apparatus each performing a portion of the operations. Where apparatus or components of apparatus are described herein as being coupled or connected to other apparatus or other components, the connection may be direct or indirect, unless the context requires otherwise.
The present invention may be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data, which can be thereafter read by a computer system. Examples of the computer readable medium include hard drives, flash drives, read-only memory, random-access memory, CD-ROMs, CD-Rs, CD-RWs, magnetic tapes, and other optical and non-optical data storage devices. The computer readable medium can also be distributed over a network-coupled computer system so that the computer readable code is stored and executed in a distributed fashion. The computer readable medium can also be distributed using a switching fabric, such as used in compute farms.
The terms “logic”, “module”, “engine” and “unit” are representative of hardware, firmware or software that is configured to perform one or more functions. As hardware, these components may include circuitry such as processing circuitry (e.g., a microprocessor, one or more processor cores, a programmable gate array, a microcontroller, an application specific integrated circuit, etc.), receiver, transmitter and/or transceiver circuitry, semiconductor memory, combinatorial logic, or other types of electronic components. When implemented in software, the logic, modules, engines, and units may be in the form of one or more software modules, such as executable code in the form of an executable application, an operating system, an application programming interface (API), a subroutine, a function, a procedure, an applet, a servlet, a routine, source code, object code, a script, a shared library/dynamic load library, or one or more instructions. These software modules may be stored in any type of a suitable non-transitory storage medium, or transitory storage medium (e.g., electrical, optical, acoustical or other form of propagated signals such as carrier waves, infrared signals, or digital signals). Examples of non-transitory storage medium may include, but are not limited or restricted to a programmable circuit; a semiconductor memory; non-persistent storage such as volatile memory (e.g., any type of random access memory “RAM”); persistent storage such as non-volatile memory (e.g., read-only memory “ROM”, power-backed RAM, flash memory, phase-change memory, etc.), a solid-state drive, hard disk drive, an optical disc drive, or a portable memory device. As firmware, the executable code is stored in persistent storage. Software is operational when executed by processing circuitry. Execution may be in the form of direct execution, emulation, or interpretation.
Lastly, the terms “or” and “and/or” as used herein are to be interpreted as inclusive or meaning any one or any combination. Therefore, “A, B or C” or “A, B and/or C” mean “any of the following: A; B; C; A and B; A and C; B and C; A, B and C.” An exception to this definition will occur only when a combination of elements, functions, steps or acts are in some way inherently mutually exclusive.
It will be appreciated by those of ordinary skill in the art that modifications to and variations of the above-described embodiments of a system and method of detecting bootkits may be made without departing from the inventive concepts disclosed herein. Accordingly, the specification and drawings are to be regarded as illustrative rather than restrictive, and the invention should not be viewed as limited except as by the scope and spirit of the appended claims. It will be recognized that the terms “comprising,” “including,” and “having,” as used herein, are specifically intended to be read as open-ended terms of art.
Number | Name | Date | Kind |
---|---|---|---|
4292580 | Ott et al. | Sep 1981 | A |
5175732 | Hendel et al. | Dec 1992 | A |
5440723 | Arnold et al. | Aug 1995 | A |
5537540 | Miller et al. | Jul 1996 | A |
5657473 | Killean et al. | Aug 1997 | A |
5842002 | Schnurer et al. | Nov 1998 | A |
5978917 | Chi | Nov 1999 | A |
6088803 | Tso et al. | Jul 2000 | A |
6094677 | Capek et al. | Jul 2000 | A |
6269330 | Cidon et al. | Jul 2001 | B1 |
6279113 | Vaidya | Aug 2001 | B1 |
6298445 | Shostack | Oct 2001 | B1 |
6357008 | Nachenberg | Mar 2002 | B1 |
6424627 | Sorhaug et al. | Jul 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 |
6775657 | Baker | Aug 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 |
6971097 | Wallman | Nov 2005 | B1 |
6981279 | Arnold et al. | Dec 2005 | B1 |
7007107 | Ivchenko et al. | Feb 2006 | B1 |
7028179 | Anderson et al. | Apr 2006 | B2 |
7043757 | Hoefelmeyer et al. | May 2006 | B2 |
7069316 | Gryaznov | Jun 2006 | B1 |
7080408 | Pak et al. | Jul 2006 | B1 |
7093002 | Wolff et al. | Aug 2006 | B2 |
7093239 | van der Made | Aug 2006 | B1 |
7100201 | Izatt | Aug 2006 | B2 |
7159149 | Spiegel et al. | Jan 2007 | B2 |
7231667 | Jordan | Jun 2007 | B2 |
7240364 | Branscomb et al. | Jul 2007 | B1 |
7240368 | Roesch et al. | Jul 2007 | B1 |
7287278 | Liang | Oct 2007 | B2 |
7308716 | Danford et al. | Dec 2007 | 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 |
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 |
7565550 | Liang et al. | Jul 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 |
7676841 | Sobchuk et al. | Mar 2010 | B2 |
7698548 | Shelest et al. | Apr 2010 | B2 |
7707633 | Danford et al. | Apr 2010 | B2 |
7779463 | Stolfo et al. | Aug 2010 | B2 |
7784097 | Stolfo et al. | Aug 2010 | B1 |
7832008 | Kraemer | Nov 2010 | B1 |
7849506 | Dansey et al. | Dec 2010 | B1 |
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 |
7937761 | Bennett | May 2011 | B1 |
7996556 | Raghavan et al. | Aug 2011 | B2 |
7996836 | McCorkendale 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 |
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 |
8201246 | Wu et al. | Jun 2012 | B1 |
8204984 | Aziz et al. | Jun 2012 | B1 |
8220055 | Kennedy | Jul 2012 | B1 |
8225288 | Miller et al. | Jul 2012 | B2 |
8225373 | Kraemer | Jul 2012 | B2 |
8233882 | Rogel | Jul 2012 | B2 |
8234709 | Viljoen et al. | Jul 2012 | B2 |
8239944 | Nachenberg et al. | Aug 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 |
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 |
8510827 | Leake et al. | Aug 2013 | B1 |
8510842 | Amit et al. | Aug 2013 | B2 |
8516593 | Aziz | Aug 2013 | B2 |
8528086 | Aziz | Sep 2013 | B1 |
8539582 | Aziz et al. | Sep 2013 | B1 |
8549638 | Aziz | Oct 2013 | B2 |
8561177 | Aziz et al. | Oct 2013 | B1 |
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 |
8713681 | Silberman et al. | Apr 2014 | B2 |
9087199 | Sallam | Jul 2015 | B2 |
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 |
20020144156 | Copeland, III | Oct 2002 | A1 |
20020162015 | Tang | Oct 2002 | A1 |
20020166063 | Lachman 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 |
20030074578 | Ford et al. | Apr 2003 | A1 |
20030084318 | Schertz | May 2003 | A1 |
20030115483 | Liang | Jun 2003 | A1 |
20030188190 | Aaron et al. | Oct 2003 | A1 |
20030200460 | Morota et al. | Oct 2003 | A1 |
20030212902 | Van Der Made | Nov 2003 | A1 |
20030237000 | Denton et al. | Dec 2003 | A1 |
20040003323 | Bennett et al. | Jan 2004 | A1 |
20040015712 | Szor | Jan 2004 | A1 |
20040019832 | Arnold et al. | Jan 2004 | A1 |
20040047356 | Bauer | Mar 2004 | A1 |
20040083408 | Spiegel et al. | Apr 2004 | A1 |
20040093513 | Cantrell et al. | May 2004 | A1 |
20040111531 | Staniford et al. | Jun 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 |
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 |
20050114663 | Cornell et al. | May 2005 | A1 |
20050125195 | Brendel | Jun 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 |
20050265331 | Stolfo | Dec 2005 | A1 |
20050283839 | Cowburn | Dec 2005 | A1 |
20060010495 | Cohen et al. | Jan 2006 | A1 |
20060015715 | Anderson | Jan 2006 | A1 |
20060021054 | Costa et al. | Jan 2006 | A1 |
20060031476 | Mathes et al. | Feb 2006 | A1 |
20060047665 | Neil | 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 |
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 |
20070033645 | Jones | Feb 2007 | A1 |
20070038943 | FitzGerald et al. | Feb 2007 | A1 |
20070064689 | Shin et al. | Mar 2007 | A1 |
20070094730 | Bhikkaji et al. | Apr 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 |
20070171824 | Ruello et al. | Jul 2007 | A1 |
20070174915 | Gribble et al. | Jul 2007 | A1 |
20070192500 | Lum | Aug 2007 | A1 |
20070192858 | Lum | Aug 2007 | A1 |
20070192863 | Kapoor et al. | Aug 2007 | A1 |
20070198275 | Malden et al. | Aug 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 |
20070271446 | Nakamura | Nov 2007 | A1 |
20080005782 | Aziz | Jan 2008 | A1 |
20080046781 | Childs et al. | Feb 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 |
20080184373 | Traut et al. | Jul 2008 | A1 |
20080189787 | Arnold 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 |
20080320594 | Jiang | Dec 2008 | 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 |
20090044024 | Oberheide et al. | Feb 2009 | A1 |
20090044274 | Budko et al. | Feb 2009 | A1 |
20090083369 | Marmor | Mar 2009 | A1 |
20090083855 | Apap et al. | Mar 2009 | A1 |
20090089879 | Wang et al. | Apr 2009 | A1 |
20090094697 | Provos 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 |
20090158430 | Borders | Jun 2009 | A1 |
20090187992 | Poston | Jul 2009 | A1 |
20090193293 | Stolfo et al. | Jul 2009 | A1 |
20090199296 | Xie et al. | Aug 2009 | A1 |
20090228233 | Anderson et al. | Sep 2009 | A1 |
20090241187 | Troyansky | 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 |
20100017546 | Poo et al. | Jan 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 |
20100192223 | Ismael et al. | Jul 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 |
20110025504 | Lyon et al. | Feb 2011 | A1 |
20110041179 | Stahlberg | Feb 2011 | A1 |
20110047594 | Mahaffey et al. | Feb 2011 | A1 |
20110047620 | Mahaffey et al. | Feb 2011 | A1 |
20110078794 | Manni et al. | Mar 2011 | A1 |
20110093951 | Aziz | Apr 2011 | A1 |
20110099633 | Aziz | Apr 2011 | A1 |
20110113231 | Kaminsky | May 2011 | A1 |
20110145920 | Mahaffey et al. | Jun 2011 | A1 |
20110167494 | Bowen et al. | Jul 2011 | A1 |
20110219450 | McDougal et al. | Sep 2011 | A1 |
20110247072 | Staniford et al. | Oct 2011 | A1 |
20110265182 | Peinado et al. | Oct 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 |
20120079596 | Thomas et al. | Mar 2012 | A1 |
20120084859 | Radinsky et al. | Apr 2012 | A1 |
20120117652 | Manni et al. | May 2012 | A1 |
20120174186 | Aziz 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 |
20120255017 | Sallam | Oct 2012 | A1 |
20120278886 | Luna | Nov 2012 | A1 |
20120297489 | Dequevy | Nov 2012 | A1 |
20120330801 | McDougal et al. | Dec 2012 | A1 |
20130036472 | Aziz | Feb 2013 | A1 |
20130047257 | Aziz | Feb 2013 | A1 |
20130097706 | Titonis et al. | Apr 2013 | A1 |
20130111587 | Goel et al. | May 2013 | A1 |
20130160130 | Mendelev et al. | Jun 2013 | A1 |
20130160131 | Madou et al. | Jun 2013 | A1 |
20130227691 | Aziz et al. | Aug 2013 | A1 |
20130246370 | Bartram et al. | Sep 2013 | A1 |
20130263260 | Mahaffey et al. | Oct 2013 | A1 |
20130291109 | Staniford et al. | Oct 2013 | A1 |
20130298243 | Kumar et al. | Nov 2013 | A1 |
20140053260 | Gupta et al. | Feb 2014 | A1 |
20140053261 | Gupta et al. | Feb 2014 | A1 |
20140351935 | Shao et al. | Nov 2014 | A1 |
Number | Date | Country |
---|---|---|
2439806 | Jan 2008 | GB |
WO-0206928 | Jan 2002 | WO |
WO-0223805 | Mar 2002 | WO |
WO-2007-117636 | Oct 2007 | WO |
WO-2008041950 | Apr 2008 | WO |
WO-2011084431 | Jul 2011 | WO |
WO-2012145066 | Oct 2012 | WO |
Entry |
---|
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). |
Bayer, et al., “Dynamic Analysis of Malicious Code”, J Comput Virol, Springer-Velag, France., (2006), pp. 67-77. |
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. |
Kristoff, J. , “Botnets, Detection and Mitigation: DNS-Based Techniques”, NU Security Day, (2005), 23 pages. |
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. |
Williamson, Matthew M., “Throttling Viruses: Restricting Propagation to Defeat Malicious Mobile Code”, ACSAC Conference, Las Vegas, NV, USA, (Dec. 2002), pp. 1-9. |
IEEE Xplore Digital Library Sear Results for “detection of unknown computer worms”, Http://ieeexolore.ieee.org/searchresult.jsp?SortField=Score&SortOrder=desc&ResultC . . . , (Accessed on Aug. 28, 2009). |
AltaVista Advanced Search Results. “Event Orchestrator”, Http://www.altavista.com/web/results?Itag=ody&pg=aq&aqmode=aqa.Event+Orchesrator . . . , (Accessed on Sep. 3, 2009). |
AltaVista Advanced Search Results. “attack vector identifier”, Http://www.altavista.com/web/results?Itag=odv&pg=aq&aqmode=aqa=Event+Orchestrater . . . , (Accessed on Sep. 15, 2009). |
Cisco, Configuring the Catalyst Switched Port Analyzer (SPAN) (“Cisco”), (1999-2003). |
Reiner Sailer, Enriciuillo Valdez, Trent Jaeger, Roonald Perez, Leendert van Doorn, John Linwood Griffin, Stefan Berger., sHype: Secure Hypervisor Appraoch to Trusted Virtualized Systems (Feb. 2, 2005) (“Sailer”). |
Excerpt regarding First Printing Date for Merike Kaeo, Designing Network Security (“Kaeo”), (2005). |
The Sniffers's Guide to Raw Traffic available at: yuba.stanford.edu/˜casado/pcap/section1.html. (Jan. 6, 2014). |
“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.jsp?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). |
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-verlag Berlin Heidelberg, (2006), pp. 165-184. |
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/g2/319(“Boubalos”) Jun. 5, 2003. |
Chaudet, C., et al., “Optimal Positioning of Active and Passive Monitoring Devices”, International Conference on Emerging Networking Experiments Technologies, Proceedings of the 2005 ACM Conference on Emerging Network Experiment and Technology, CoNEXT '05, Toulousse, France, (Oct. 2005), pp. 71-82. |
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). |
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). |
Filiol, Eric, et al., “Combinatorial Optimisation of Worm Propagation on an Unknown Network”, International Journal of Computer Science 2.2 (2007). |
Goel, et al., Reconstructing System State for Intrusion Analysis, Apr. 2008 SIGOPS Operating Systems Review, vol. 42 Issue 3, pp. 21-28. |
Hjelmvik, Erik , “Passive Network Security Analysis with NetworkMiner”, (IN)SECURE. Issue 18, (Oct. 2008), pp. 1-100. |
Kaeo, Merike , “Designing Network Security”, (“Kaeo”), (Nov. 2003). |
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”). |
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. |
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). |
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. |
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, 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. |
Peter M. Chen, and Brian D. Noble , “When Virtual Is Better Than Real, Department of Electrical Engineering and Computer Science”, University of Michigan (“Chen”). |
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). |
Thomas H. Ptacek, and Timothy N. Newsham, “Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection”, Secure Networks, (“Ptacek”), (Jan. 1998). |
Venezia, Paul , “NetDetector Captures Intrusions”, InfoWorld Issue27, (“Venezia”), (Jul. 14, 2003). |
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. |