Patent Publication Number: US-9838408-B1

Title: System, device and method for detecting a malicious attack based on direct communications between remotely hosted virtual machines and malicious web servers

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of U.S. patent application Ser. No. 15/213,306 filed Jul. 18, 2016, now U.S. Pat. No. 9,661,009 issued May 23, 2017, which is a continuation of U.S. patent application Ser. No. 14/316,714 filed Jun. 26, 2014, now U.S. Pat. No. 9,398,028 issued Jul. 19, 2016, the entire contents of which are incorporated by reference herein. 
    
    
     FIELD 
     Embodiments of the disclosure relate to the field of network and cyber security. More specifically, one embodiment of the disclosure relates to a system, device and method for detecting a malicious attack based, at least in part, on real-time communications with a web server associated with network traffic determined to be suspicious. 
     GENERAL BACKGROUND 
     Over the last decade, malicious attacks have become a pervasive problem for Internet users as most networked resources include vulnerable software. For instance, over the past few years, more and more vulnerabilities are being discovered in software that is loaded onto network endpoints, such as vulnerabilities within operating systems and applications installed on endpoint systems. While some software vulnerabilities continue to be addressed through software patches, network endpoints will continue to be targeted for attack in efforts to acquire sensitive information or adversely affect operations of various enterprises. 
     In general, efforts have been made to counter malicious attacks over web traffic. One effort has been directed to security appliances that monitor web traffic coming into an enterprise network and performs both preliminary and virtual machine (VM) based analysis of objects associated with the web traffic in order to detect the presence of exploits. Although effective in detecting malicious attacks, these types of security appliance have a few challenges. 
     In its current configuration, the security appliance handles VM-based analysis, which consumes a great amount of processing and memory resources. Due to memory and/or processing constraints that exist for all standalone security appliances, there will be limits on the number of virtual machines (VMs) as well as the number of permutations of software profiles (e.g., software images of operating systems and application versions) that can be supported by the security appliance. Also, as most of the memory and/or processing resources with the security appliance are directed to preliminary and VM-based analysis, it is difficult to introduce new or experimental features or enhancements without increased processing or memory, as such features or enhancements would equate to lesser processing and/or memory reserved for core preliminary or VM-based analysis. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Embodiments of the invention are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which: 
         FIG. 1  is an exemplary block diagram of a communication system deploying a security network device adapted to conduct a preliminary analysis on objects associated with monitored network with more in-depth (dynamic) analysis being conducted remotely at a detection cloud. 
         FIG. 2  is a more detailed block diagram of the communication system of  FIG. 1 . 
         FIG. 3A  is a first exemplary block diagram of the communication system of  FIG. 2 , where the operations conducted by the security network device and the detection cloud are described. 
         FIG. 3B  is a second exemplary block diagram of the communication system of  FIG. 2 , where the operations conducted by the security network device and the detection cloud are described. 
         FIG. 4  is a general exemplary flowchart illustrating a threat detection process, where VM-based analysis is conducted within the detection cloud separate from the security network device. 
         FIG. 5  is a more-detailed exemplary flowchart illustrating a threat detection process, where VM-based analysis is conducted within the detection cloud separate from the security network device. 
     
    
    
     DETAILED DESCRIPTION 
     Various embodiments of the disclosure relate to an electronic device with network connectivity, referred to as a “security network device” for example, which is responsible for conducting preliminary analysis of an object associated with monitored network traffic to determine whether the object appears to be part of a multi-phase malicious attack (e.g., beginning of a “drive-by attack” where an exploit is initially injected into a client device in order to effectuate subsequent downloading of the malicious payload). Upon determining that the object under analysis is suspected of being part of a malicious (drive-by) attack, the security network device uploads an identifier associated with the origin of the monitored network traffic (e.g., a Uniform Resource Locator “URL”) to a detection cloud (e.g., cloud computing services conducting dynamic analysis at a prescribed location). Virtual execution logic within the detection cloud conducts an in-depth analysis of the suspicious URL by provisioning one or more virtual machines (hereinafter, “VM(s)”) within the cloud to establish real-time communications with the malicious host. Thereafter, the behaviors of the VM(s) during communications with the source are monitored and the detected presence of certain anomalies may indicate that the network traffic is associated with a malicious (drive-by) attack. This embodiment constitutes an improvement to an existing technological process of malware detection. 
     As described below, one or more security network devices are located on-premises and are deployed within an enterprise network. For instance, a first security network device may be configured to conduct a preliminary analysis on one or more objects associated with monitored, incoming network traffic (e.g., web traffic). The preliminary analysis may include (i) pattern matching such as exploit matching; (ii) vulnerability checks; (iii) heuristic, statistical or deterministic analysis; or (iv) any combination thereof. 
     The first security network device is communicatively coupled to the detection cloud, which is configured to conduct dynamic analysis on information associated with one or more objects deemed “suspicious” by the first security network device. The dynamic analysis may involve virtual processing of the information associated with the suspicious object(s) by VM(s) deployed as part of virtual execution logic, where the detection cloud communicates directly or indirectly with a web server distributing web traffic including the suspicious object(s). The communicative coupling between the first security network device and the detection cloud may be achieved through a dedicated transmission medium or a non-dedicated transmission medium supporting secured (e.g. encrypted or otherwise obfuscated) communications. 
     According to one embodiment of the disclosure, deployed within the first security network device, a preliminary analysis engine filters objects associated with the web traffic and determines at least one identifier (e.g., URL) of a source for one or more of the objects that are determined to be “suspicious.” An object is deemed “suspicious” when there is a prescribed probability of that object being associated with a malicious attack. 
     The preliminary analysis engine transmits the identifier of the source of the suspicious object(s) for use in VM-based analysis at a location outside the confines of the housing of the first security network device, normally at a geographic location remotely located from the first security network device. Stated differently, once the URL associated with a suspicious object has been identified by the preliminary analysis engine, instead of sending the suspicious URL to one or more VMs operating within the security network device itself, the suspicious URL along with certain ancillary data is sent to the detection cloud. The ancillary data comprises (1) an identification of a customer responsible for the security network device (hereinafter, “Customer_ID”) and/or (2) a hash value for an Internet Protocol (IP) address of the client device targeted by the suspicious web traffic (hereinafter, “Hash(Client_IP_Addr)”). 
     It is contemplated that providing ancillary data (e.g., Customer_ID, Hash(Client_IP_Addr), etc.) that corresponds to the suspicious URL is useful to customize functionality of the detection cloud, especially when the number of simultaneous VMs provisioned in the detection cloud for each customer may vary. Also, the types and number of software profiles (e.g., Guest OS and applications images) provisioned for these VMs can also vary based on customer preference and/or enterprise deployment. For instance, an enterprise network deploying network devices that are capable of operating with three different operating systems (OSes), such as Windows® XP, Windows® 7 and Windows® 8 for example, may provision and utilize a greater number software profiles for dynamic analysis than an enterprise with electronic devices loaded with a single type of OS, such as Windows® 8 only. 
     Once suitable VM(s) are provisioned within the detection cloud, the VM(s) establish a communication session with a suspect (e.g., potentially malicious) source, namely a suspect web server. The communication session may be established directly using the suspicious URL and the VM-based analysis is conducted using responses from this “live” website. “Live” website inter-communications are available since the on-premise, security network device detected the suspect web server being accessed from the enterprise network moments ago. 
     In cases where a malicious attack is detected by the VMs, an alert message including details of the infection (e.g., time of infection, URL name, malware name, etc.) is generated in the detection cloud. The alert message may be returned to the on-premises security network device, where information with the alert message may be populated within the local database and/or re-routed to one or more network administrators managing the enterprise network. 
     It is contemplated that the functionality of the security network device may be implemented with any type of electronic device, such as a client device that includes a desktop computer or a mobile device such as a laptop computer, netbook, tablet computer, or smart phone. Herein, the electronic device includes the preliminary analysis logic which, upon determining that an object under analysis is suspected of being part of a malicious (drive-by) attack, uploads an identifier associated with the origin of the monitored network traffic to the detection cloud. 
     Based on direct interaction with the suspect web server, the detection cloud conducts an in-depth analysis of the suspicious object, and when determined to be malicious, provides one or more alert messages to the electronic device. The alert message may provide a displayed warning to the user regarding the malicious attack or may signal logic within the electronic device to quarantine information associated with the malicious object or to conduct remediation operations. 
     I. Terminology 
     In the following description, certain terminology is used to describe features of the invention. For example, in certain situations, both terms “logic” and “engine” are representative of hardware, firmware and/or software that is configured to perform one or more functions. As hardware, logic (or engine) may include circuitry having data processing or storage functionality. Examples of such circuitry may include, but is not limited or restricted to a microprocessor, one or more processor cores, a programmable gate array, a microcontroller, an application specific integrated circuit, wireless receiver, transmitter and/or transceiver circuitry, semiconductor memory, or combinatorial logic. 
     Logic (or engine) may be software in the form of one or more software modules, such as executable code in the form of an executable application, an application programming interface (API), a subroutine, a function, a procedure, an applet, a servlet, a routine, source code, object code, 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. 
     The term “object” generally refers to a collection of data, such as a group of related packets associated with a request-response message pairing for example, normally having a logical structure or organization that enables classification for purposes of analysis. For instance, an object may be a self-contained element, where different types of such objects may include an executable file, non-executable file (such as a document or a dynamically link library), a Portable Document Format (PDF) file, a JavaScript file, Zip file, a Flash file, a document (for example, a Microsoft® Office® document, etc.), an electronic mail (email), downloaded web page, and/or an instant message accordance with Session Initiation Protocol (SIP) or another messaging protocol. 
     The term “flow” generally refers to a collection of related objects (e.g., messages), communicated during a single communication session between a single source network device (e.g., client device) and a single destination network device (e.g., server). For instance, a first flow (GET HTTP Request message) may be user initiated while subsequent flows (e.g., other HTTP messages initiated to complete the GET HTTP Request message) may be initiated automatically without user intervention. 
     A “communication session” may be defined as a semi-permanent information exchange between source and destination network devices. For example, the communication session may be in accordance with protocols at the application layer (e.g., Hypertext Transfer Protocol “HTTP”), session layer, or transport layer (e.g., Transmission Control Protocol “TCP”) of the Open Systems Interconnection (OSI) model. 
     A “message” generally refers to information transmitted in a prescribed format, where each message may be in the form of one or more packets, frames, HTTP-based transmissions, or any other series of bits having the prescribed format. 
     The term “transmission medium” is a physical or logical communication path between two or more electronic devices (e.g., any devices with data processing and network connectivity such as, for example, a server, a mainframe, a computer such as a desktop or laptop, netbook, tablet, firewall, smart phone, router, switch, bridge, etc.). For instance, the communication path may include wired and/or wireless segments, and/or shared memory locations. Examples of wired and/or wireless segments include electrical wiring, optical fiber, cable, bus trace, or a wireless channel using infrared, radio frequency (RF), or any other wired/wireless signaling mechanism. 
     The term “computerized” generally represents that any corresponding operations are conducted by hardware in combination with software and/or firmware. Also, the terms “compare” or “comparison” generally mean determining if a match (e.g., a certain level of matching) is achieved between two items where one of the items may include a particular signature pattern. 
     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. 
     As this invention is susceptible to embodiments of many different forms, it is intended that the present disclosure is to be considered as an example of the principles of the invention and not intended to limit the invention to the specific embodiments shown and described. 
     II. Exemplary Architectures 
     Referring to  FIG. 1 , an exemplary block diagram of a communication system  100  deploying a security network device  120 , which is an electronic device that is deployed within an enterprise network  110  and adapted to analyze information associated with network traffic  130  received via a communication network  140 . The communication network  140  may include a public network such as the Internet, in which case one or more network devices, such as a firewall for example, may be positioned in-front of or integrated into the security network device  120 . Alternatively, the communication network  140  may be a private network such as a wireless data telecommunication network, wide area network, a type of local area network (LAN), or a combination of networks. 
     Herein, the security network device  120  may be one of a plurality of security network devices  150  that are geographically distributed from each other and communicatively coupled to a management system  160 . The geographic distribution of the security network devices  150  may enable scalability to support growth of the enterprise network, and reduced customer response time in conducting dynamic analysis of submitted identifiers (e.g. URLs) based on distribution of work load in communications with detection cloud  180 . 
     As shown, security network device  120 , upon detection of suspicious network traffic, namely traffic having a prescribed probability of being part of a malicious attack, transmits information associated with the suspicious network traffic. For instance, as an illustrative example, the security network device  120  may transmit the URL associated with the suspicious traffic (sometimes referred to as the “suspicious URL”) to detection cloud  180  that establishes communications with the potential malicious web server  190  for subsequent analysis of the communications. 
     Referring still to  FIG. 1 , the management system  160  may be adapted to manage the security network devices  150 , including security network device  120 . For instance, the management system  160  may be responsible for updating software executed by one or more hardware processors within the security network device  120 . Such updating may be conducted automatically or conducted manually via uploads by an administrator. Also, such updating may be conducted freely among the security network devices or subject to a service subscription. 
     Of course, it is contemplated that, as an alternative embodiment, the functionality of the security network device  120  may be implemented with any or all of the client devices  170   1 - 170   M  (where M≧1). Examples of the client devices  170   1 - 170   M  include tablet computer, desktop or laptop computer, or smart phone. For clarity sake, the architecture and functionality of security network device  120  is described below. 
     Referring now to  FIG. 2 , the security network device  120  comprises a preliminary analysis engine  200  that is configured to analyze characteristics of objects associated with the network traffic  130 . In particular, the preliminary analysis engine  200  may include one or more software modules that, when executed by one or more hardware processors located within the security network device  120 , operate as a filter that (i) parses the incoming network traffic, (ii) aggregates and analyzes information associated with characteristics of the network traffic from the same source for a given communication session, and (iii) optionally stores information associated with the characteristics within the data store  240 . 
     More specifically, preliminary analysis engine  200  may be configured with exploit matching logic  210 , vulnerability matching logic  220  and/or heuristic logic  230 . Exploit matching logic  210  is adapted to perform exploit signature checks, which may involve a comparison of a suspect object against one or more pre-stored exploit signatures (e.g., pre-configured and predetermined attack patterns) from signature database  215 . Additionally or in the alternative, the preliminary analysis engine  200  may be configured with vulnerability matching logic  220  that is adapted to perform vulnerability signature checks, which may include a process of uncovering deviations in messaging practices set forth in applicable communication protocols (e.g., HTTP, TCP, etc.). 
     Also, additionally or in the alternative, the preliminary analysis engine  200  may be configured with heuristic logic  230  that is adapted for analysis of certain portions of an object to determine whether any portion corresponds to a “suspicious identifier.” An example of a suspicious identifier may include, but are not limited or restricted to a particular URL that is associated with known exploits, a particular source or destination address that is associated with known exploits; particular exploit patterns; or particular shell code patterns. 
     A statistical analysis engine  245  may be configured, based on statistical analysis of the object under analysis, to generate a score value that represents a probability (or level of confidence) that this object is associated with a malicious attack. For instance, the score value may be based, at least in part, on (i) pattern matches; (ii) analyzed deviations in messaging practices set forth in applicable communication protocols (e.g., HTTP, TCP, etc.); (iii) analyzed compliance with certain message formats established for the protocol (e.g., out-of-order commands); and/or (iv) analyzed header or payload parameters to determine compliance. Where the score value exceeds a prescribed value (e.g., 9 out of 10), the object under analysis is deemed “suspicious”. This score determination may also require assistance of some emulation (e.g. Javascript® emulation) techniques to de-obfuscate certain object types before they can be analyzed. 
     After the object under analysis is determined to be suspicious, the security network device  120  generates preliminary analysis results  250 . The preliminary analysis results  250  are uploaded to a dynamic analysis engine  260  of the detection cloud  180 , where the dynamic analysis engine  260  is responsible for dynamic analysis of network traffic resulting from accessing a website designated by the suspicious URL. According to one embodiment, the preliminary analysis results  250  comprise (1) a URL  252  associated with the website hosted by a potentially malicious web server  190  that previously provided the network traffic including the suspicious object, (2) an identifier  254  for an entity (company, individual, governmental department, etc.) that owns, leases or is responsible for the security network device  120  (hereinafter, “Customer_ID”  254 ), and/or (3) a hash value  256  for an Internet Protocol (IP) address of a client device  170   1  targeted by the suspicious network traffic (hereinafter, “Hash(Client_IP_Addr)”  256 ). Optionally, the preliminary analysis results  250  may include the score value  258  generated by the statistical analysis engine  245 . 
     According to one embodiment of the disclosure, the detection cloud  180  is a cloud computing service that is geographically remote from the security network device  120  and is responsible for conducting an in-depth analysis of resultant communications with a web server hosting a website designated by the suspicious URL. As an alternative embodiment, the detection cloud  180  may be implemented within a secure/isolated sub-network of the enterprise network rather than outside the enterprise network. 
     This in-depth analysis comprises virtual processing information received from communications with a website designated by the suspicious URL in order to determine (i) whether the communications are associated with a malicious attack and (ii) whether the web server providing such communications is infected with malware. The later determination may prompt placement of the web server onto a blacklist and/or cause the detection cloud  180  to transmit a message to notify the web server, either directly or through a third party (e.g., Internet service provider “ISP”, wireless carrier, governmental agency, etc.) of the detected malicious attack. In general, under control of controller  270 , data extraction logic  275  receives the preliminary analysis results  250  and extracts the URL  252 , the Customer_ID  254 , the Hash(Client_IP_Addr)”  256 , and/or score value  258 . 
     The URL  252  is used during virtual processing operations conducted by the dynamic analysis engine  260  to communicate with the web server  190  that distributed the suspicious web traffic in efforts to determine if the web server  190  is malicious (e.g., compromised servers that are unknowingly infected with malware so as to unintentionally propagate exploits to other network devices; server designed to infect network devices with particular exploits, etc.). 
     The Customer_ID  254  identifies the enterprise network  110  (and/or the specific security network device  120 ) that detected suspicious web traffic under further analysis by the virtual execution logic  280 . The Customer_ID  254  ensures that the dynamic analysis results  290  are correctly returned. Additionally, through a customer portal, each customer may choose a configuration of guest images that are run within a provisioned virtual machine of the one or more virtual machines (VMs)  285   1 - 285   N  (N≧1) operating inside the detection cloud  180 . As a result, the Customer_ID  254  and/or the Hash(Client_IP_Addr)  256  may be used for provisioning one or more VMs  285   1 - 285   N  with different types and/or versions of operating systems (e.g., Windows®-based OS, MAC-based OS, Windows® Mobile OS, Android®, iOS®, etc.), different types and/or versions of browser or other applications (e.g., Internet Explorer®, Mozilla®, Chrome®, FireFox®, Adobe Reader 8.0, MS Office 2013 etc.) supported by and available to the virtual execution logic  280 . The Hash(Client_IP_Addr)  256  may also be used for recording purposes to identify targeted client devices. The goal of this customization is to get the closest possible match to the operating system and application versions that are running on the endpoints in the customer&#39;s network. 
     Aspects of the invention may be practiced for providing malware detection services to customers who, for example, avail themselves of the services on a paid subscription basis. For instance, where the customer subscribes to a particular service level, the Customer_ID  254  may cause the dynamic analysis engine  260  to provision a first set of VMs (e.g., “X” VMs) or provision VMs until a first prescribed VM capacity level has been reached (e.g. 100 simultaneous VMs). Where additional VM capacity may be necessary to provision VMs for additional OS or application configurations that may be necessary to provide a complete analysis (e.g., where targeted client device identified by Hash(Client_IP_Addr) is capable of supporting a large subset of browsers), the controller  270  may issue an alert message to network security personnel of the enterprise network  110  for authorization to increase the subscription level that would enable VMs to be provisioned until a second prescribed VM capacity level has been reached (e.g., 200 simultaneous VMs). 
     After the VMs  285   1 - 285   N  have been provisioned, the virtual execution logic  280  virtually processes the suspicious URL  252  which initiates a HTTP Request message that is sent to the web server  190  and establishes a communication session with the web server  190  or another web server for re-direction to web server  190 . Such redirection is intended to provide an added level of protection from being detected by malware and malicious actors. Subsequent communications during the established communication session are monitored for anomalous behaviors, such as receiving content with embedded executables that alter registry keys of the OS, upload of a subroutine such as Command and Control (CnC) exploit, receipt of call-back commands, etc. Monitoring logic  287  within the virtual execution logic  280  captures the anomalous behaviors, which are subsequently reported to the security network device  120  or another network device within the enterprise network  110  for reporting to network administrator(s). 
     III. Exemplary Detection Cloud Threat Detection Processes 
     Referring to  FIG. 3A , a first exemplary block diagram of the communication system  100  is shown, where the operations conducted by the security network device  120  and the detection cloud  180  are identified. According to one embodiment of the disclosure, the security network device  120  analyzes portions of incoming web traffic (operation_1). 
     Upon determining that an object associated with monitored web traffic appears to be part of a multi-phase malicious attack (e.g., beginning of a “drive-by attack” where the exploit is loaded and the malicious payload is loaded subsequently), the security network device  120  submits the preliminary analysis results  250  to the detection cloud  180  via communication interface  300  (operation_2). Of course, as an alternative embodiment, the network security device may only upload the preliminary analysis results to the detection cloud  180  if the customer subscribes to that service and/or the score value assigned to the object is above a certain threshold. 
     As described above, the preliminary analysis results  250  comprise a first identifier (e.g., URL)  252  associated with the website hosted by a potentially malicious web server  190 , (2) a second identifier  254  (e.g., Customer_ID) that identifies the customer responsible for the security network device  120 , and/or (3) a third identifier  256  (e.g., Hash(Client_IP_Addr)) that can be used to identify the IP address of the client device  170   1  targeted by the suspicious web traffic as shown in  FIG. 2 . 
     Upon receipt by the detection cloud  180 , a scheduler  310  receives the preliminary analysis results  250  and stores contents of the preliminary analysis results  250  into a first data store  315  (operation_3 and operation_4). The first data store  315  is accessible by scheduler  310 , reputation logic  330 , VM provisioning logic  340 , dynamic analysis engine  260 , and/or alert generation logic  380 . 
     Thereafter, the scheduler  310  conducts a look-up of a second data store  320  to identify guest software images, namely software images of operating systems, applications or other software components for provisioning one or more VMs  285   1 - 285   N  (operation_5). The identification as to which software profiles for use in provisioning the VMs  285   1 - 285   N  may be accomplished through the use of the Customer_ID to identify the customer with ownership of the enterprise network and/or the Hash(IP Client Addr) to identify the specific client device(s) targeted to receive the suspicious web traffic. 
     For instance, based on the Customer_ID, the scheduler  310  operating in combination with VM provisioning logic  340  may configure VMs  285   1 - 285   N  with software profiles corresponding to software images stored within client devices  170   1 - 170   M  of  FIG. 1  that are actually implemented within the enterprise network  110 . As an alternative embodiment, the VMs  285   1 - 285   N  may be configured according to different types and/or versions of software configurations that can be used by client devices  170   1 - 170   M  connected to enterprise network  110  (e.g., client device  230 ) or even the most prevalent types of software configurations (e.g., a Windows® 8 OS; a popular version of Internet Explorer® web browser currently in use; popular version of Adobe® PDF™ reader application currently in use, etc.) or simply an appropriate software profile to process the content. 
     As an optional feature shown in dashed lines, the detection cloud  180  may comprise reputation logic  330  that conducts operations to customize and/or optimize operability of the virtual execution logic  280  (operation_6). Stated differently, one function of the reputation logic  330  is to avoid conducting dynamic analysis associated with suspicious URLs that are already determined to be malicious or benign. 
     For instance, the reputation logic  330  may operate in combination with the scheduler  310  to select software profiles (e.g., guest images) that are more prone to attack by Japanese-based websites in lieu of U.S. based websites where the detection cloud  180  handles network traffic in Japan. Additionally, the reputation logic  330  may include blacklists or whitelists that identify URLs determined to be non-malicious, perhaps including age-based results to identify stale results by recording the last time that the URL was determined to be non-malicious. A match of the blacklist may prompt the reputation logic  330  to transmit data for generation of an alert message (operation_7). This alert message will be identical to a Web-infection alert generated locally on the security device  120  in its current shipping version. 
     Herein, the VM provisioning logic  340  receives the selected guest software images along with the Customer_ID (operation_8). The Customer_ID may be used to determine, for the particular customer, a maximum number of simultaneous VMs allowed to run in the detection cloud  180  for that particular customer. If processing and/or storage capacities are approaching or have exceeded maximums so that all of the selected guest images cannot be provisioned to concurrently run (at the same time or in an overlapping manner) on the VMs, information is provided to alert generation logic  380  to generate a message that alerts network security personnel of the customer associated with the enterprise network that he/she may want to alter its subscription to increase execution capacity (operation_9). 
     Thereafter, the VMs  285   1 - 285   N  are provisioned within the virtual execution logic (operation_10) and subsequently launched. Upon launching, one or more VMs commence to virtually execute a browser application which now attempts to access a website hosted by the “live” web server  190  using the suspicious URL and establish a communication session (operations_11&amp;12). For instance, a first VM  285   1  that virtually executes the browser application transmits a GET, POST or other HTTP request message to web server  190  using the suspicious URL. 
     In response, the web server  190  hosting the accessed website returns information, perhaps as part of a response message, to the first VM  285   1  (operation_13). Monitoring logic  287  within the virtual execution logic  280  may be configured to monitor behaviors of one or more VMs  285   1 , . . . , and/or  285   N , such as VM  285   1  configured to execute the browser application that launched the suspicious URL (operation  14 ). This monitoring is conducted to detect anomalous (unexpected or irregular) activity indicative of an exploit. When anomalous activity is detected, the monitoring logic  287  operating with an optional score determination logic (not shown) may route VM-based results  360  (e.g., computed score, information associated with the detected anomalous behaviors, and other information associated with the detected malicious activity by the suspect object) to the alert generation logic  380  (operation_15). Of course, as an option, the security network device  120  may conduct further analysis on information from the web server  190  in parallel with (at the same time or in an overlapping manner) or following the virtual processing by the virtual execution logic  280 . 
     While monitoring logic  287  analyzes information exchanged with the web server  190 , the first VM  285   1  continues its communication session with the web server  190  (operation_16). The communication session is maintained until a prescribed time has elapsed or the monitoring logic  287  has conducted sufficient operations to determine that the web server  190  is malicious or non-malicious. 
     Although not shown, it is noted that score determination logic may be implemented within the dynamic analysis engine  260  or the alert generation logic  380  so that VM-based results  360  may be subsequently weighted by the alert generation logic  380  upon reporting the findings by the virtual execution logic  280 . 
     Optionally, prior to passing the information from the web server  190  to the virtual execution logic  280 , secondary analysis logic  350  may initially conduct additional operations (e.g., emulation, heuristics, etc.) on the information in order to determine whether the content within the response can be determined to be malicious or benign without further processing by the VMs  285   1 - 285   N  (operation_17). For instance, secondary analysis logic  350  may compare the page URL, returned content and software profile with similar responses of both malicious and non-malicious servers. 
     If a match is found, where the match is directed to a response from a malicious server, according to one embodiment, results  370  of the secondary analysis are provided to the alert generation logic  380  to produce one or more alert messages to represent that the URL is associated with a malicious server. Otherwise, the virtual execution logic  280  may be notified that the URL is associated with a non-malicious server and to discontinue further virtual processing associated with the suspicious URL. 
     Upon receiving the VM-based results  360  or the secondary analysis results  370 , the alert generation logic  380  generates alert messages  390  to identify that the web traffic is associated with a malicious attack based on analyzed interaction with a malicious web server (operation_18). The alert messages  390  are routed to the security network device  120 , which conducts certain post-processing operations such as mapping the alert message to a corresponding client device using the hash(IP Client Addr) and/or storing the alert message for subsequent conveyance for display and access by network security personnel of the enterprise network  110  (operation_19). 
     Referring to  FIG. 3B , a second exemplary block diagram of the communication system  100  is shown, where operations conducted by the security network device  120  and the detection cloud  180  are described. According to this embodiment of the disclosure, a set of anonymizing proxies  395  is positioned between the detection cloud  180  and the web server  190  (operations_12A/12B/13A/13B). The anonymizing proxy  395  operates to obfuscate the origination of the HTTP GET or POST request so that the web server  190  does not create defenses by refraining to transmit exploits for access requests within the client IP address range. 
     IV. Exemplary Threat Detection and Prevention Processes 
     Referring to  FIG. 4 , a general exemplary flowchart illustrating a threat detection process is shown, where VM-based analysis is conducted within a detection cloud separate from the security network device. First, the detection cloud receives, from a security network device, an identifier (e.g., a URL) that sources objects from monitored web traffic that are determined to be “suspicious” (block  400 ). The security network device is implemented within an enterprise network and has secured access to the detection cloud. In response to receipt of the suspicious identifier, logic within the detection cloud provisions one or more VMs within the virtual execution logic and conducts virtual processing of the suspicious identifier (blocks  410  and  420 ). During virtual processing of the suspicious identifier, one or more web servers are accessed to retrieve information therefrom. 
     During virtual processing, the behaviors of the one or more VMs are monitored and a determination is made as to whether any anomalous behaviors (e.g., processing or communication behaviors) have been detected (blocks  430  and  440 ). If not, a determination is made as to whether the virtual processing of the suspicious identifier has completed (block  450 ). If the virtual processing has completed, the threat detection process ends. Otherwise, the virtual processing continues and the resultant behaviors of the one or more VMs are monitored. 
     Upon detecting anomalous behaviors by the one or more VMs during virtual processing, one or more alert messages may be generated. An alert message may comprise the URL now determined to be associated with a malicious web server along with information associated with the detected anomalous behaviors and the Hash(IP Client Addr) to identify the targeted client device (block  460 ). Thereafter, as set forth in block  470 , the alert message is sent to the security network device within the enterprise network for post-processing and providing such findings in a manner that can be perceived by network security personnel (e.g., GUI display, audio message, text message, etc.). 
     Referring to  FIG. 5 , a more-detailed exemplary flowchart illustrating a threat detection process is shown, where VM-based analysis is conducted within a detection cloud separate from the security network device. First, the detection cloud receives, from a security network device, a URL that sources objects from monitored web traffic that are determined to be “suspicious” along with ancillary metadata that may be used for customer identification, VM provisioning and reporting purposes (block  500 ). The security network device is implemented within an enterprise network associated with a particular client and has secured access to the detection cloud. In response to receipt of the suspicious URL and corresponding metadata, logic within the detection cloud provisions one or more VMs within virtual execution logic deployed within the detection cloud and conducts virtual processing of the suspicious URL (blocks  510  and  520 ). During virtual processing of the suspicious URL, one or more web servers are accessed to retrieve information therefrom (blocks  530 - 550 ). 
     During virtual processing, the behaviors of the one or more VMs are monitored by the monitoring logic and a determination is made as to whether any anomalous behaviors have been detected (block  560 ). Upon detecting anomalous behaviors by the one or more VMs during virtual processing, the information associated with the anomalous behaviors is reported back to the enterprise network, such as providing a return message to the security network device (block  570 ). 
     In the foregoing description, the invention is described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims.