Electronic Message Analysis for Malware Detection

BACKGROUND

0001Presently, malicious network content (e.g., malicious software or malware) can attack various devices via a communication network. For example, malware may include any program or file that is harmful to a computer user, such as bots, computer viruses, worms, Trojan horses, adware, spyware, or any programming that gathers information about a computer user or otherwise operates without permission.

0002Various processes and devices have been employed to prevent the problems that malicious network content can cause. For example, computers often include antivirus scanning software that scans a particular client device for viruses. Computers may also include spyware and/or adware scanning software. The scanning may be performed manually or based on a schedule specified by a user associated with the particular computer, a system administrator, and so forth. Unfortunately, by the time a virus or spyware is detected by the scanning software, some damage on the particular computer or loss of privacy may have already occurred. Additionally, it can take days or weeks for new Anti-Virus signatures to be manually created and for an anti-virus application to be updated, by which time malware authors will have already created new versions that evade the signatures. Moreover, polymorphic exploits are also an issue that limits the effectiveness of some anti-virus applications.

0003Malicious network content may be distributed over a network via web sites, e.g., servers operating on a network according to an HTTP standard. Malicious network content distributed in this manner may be actively downloaded and installed on a user's computer, without the approval or knowledge of the user, simply by accessing the web site hosting the malicious network content. The web site hosting the malicious network content may be referred to as a malicious web site. The malicious network content may be embedded within data associated with web pages hosted by the malicious web site. For example, a web page may include JavaScript code, and malicious network content may be embedded within the JavaScript code. In this example, the malicious network content embedded within the JavaScript code may be obfuscated such that it is not apparent until the JavaScript code is executed that the JavaScript code contains malicious network content. Therefore, the malicious network content may attack or infect a user's computer before detection by antivirus software, firewalls, intrusion detection systems, or the like.

0004Additionally, malicious network content may be distributed by electronic messages, including email, using such protocols as POP, SMTP, IMAP, and various forms of web-based email. Malicious content may be directly attached to the message (for example as a document capable of exploiting a document reading application, such as a malicious Microsoft Excel document). Alternatively, electronic messages may contain URL links to malicious content hosted on web servers elsewhere on the network. When target users click on such links, they may be infected from the web in the manner described above. These techniques for infecting user computers via electronic messages are often used to make targeted attacks on particular “high-value” users at organizations, such as executives or key technical or operational staff.

0005What is needed is an improved system for detecting malicious content propagated in electronic messages.

SUMMARY

0006The present technology analyzes an electronic message for malware contained in the message. Systems that analyze electronic messages typically analyze attached files for malware. The content of an electronic message itself may contain text, which is usually not examined by malware systems. The present technology analyzes text of an electronic message to detect and process malware content in the electronic message itself. In some embodiments, the present technology may analyze an electronic message to detect a uniform resource location (URL), identify whether the URL is suspicious, and analyze all suspicious URLs to determine if they are malware. The analysis may include re-playing the suspicious URL in a virtual environment which simulates the intended computing device to receive the electronic message. If the re-played URL is determined to be malicious, the malicious URL is added to a black list which is updated throughout the computer system.

0007In an embodiment, malicious network content may be detected by a network content processing system by receiving an electronic message. The electronic message may be determined to include content determined to be suspicious. The suspicious electronic message content may be executed in a virtual environment. The suspicious electronic message content may be identified as malicious based on execution of the suspicious electronic message content in the virtual environment.

BRIEF DESCRIPTION OF FIGURES

0008<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of an exemplary system for detecting malicious electronic messages.

0009<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram of an exemplary e-mail malware detection module.

0010<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram of an exemplary management server.

0011<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart of an exemplary method for detecting malicious electronic messages.

0012<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart of an exemplary method for identifying a suspicious URL.

0013<figref idref="DRAWINGS">FIG. 6</figref> is a flowchart of an exemplary method for identifying suspicious URLs.

0014<figref idref="DRAWINGS">FIG. 7</figref> is a flowchart of an exemplary method for updating a malware detection system.

0015<figref idref="DRAWINGS">FIG. 8</figref> is a block diagram of an exemplary computing device.

DETAILED DESCRIPTION

0016The present technology analyzes electronic messages for malware contained in the message. Systems that analyze electronic messages typically analyze attached files for malware in synthetic environments such as a virtual environment. Unlike prior systems, the present technology may analyze the content of an electronic message to detect malware in the message content. For example, the content may include a uniform resource locator (URL) address. The URL address may be analyzed to determine if the URL address is associated with malware. Additionally, the present technology may analyze attachments in a real operating system running in an instrumented virtual environment. In addition to analyzing the content within an email itself, the present technology may process attachments for emails that provide a location associated with malware. The attachments may include one or more files compatible with common applications, including Word, Excel and Powerpoint applications by Microsoft Corporation, of Redmond, Wash., and Adobe Reader application, by Adobe Systems Inc., of San Jose, Calif.

0017In some embodiments, the present technology may analyze an electronic message to detect a URL, identify whether the URL is suspicious, and analyze the suspicious URL to determine if it describes a location associated with malware. Determining if the URL is suspicious may include if comparing the URL to one or more lists of URLs. For example, the URL may be compared to a white list of acceptable URLS, a black list of malware URLs, and/or a list having a combination of URLs. If the URL is not found on any list, the URL is not determined to be malware and not determined to be acceptable, and therefore may be determined to be suspicious.

0018Analysis of a suspicious URL may include re-playing the suspicious URL in a virtual environment which simulates the intended computing device to receive the electronic message. Re-playing a URL may include executing the URL by a virtual component in the virtual environment to request content located from the URL address. Content is received by the virtual environment in a URL request response, the received content is loaded into the virtual environment, and executed while the virtual environment is monitored. If the re-played URL is determined to be malicious, the malicious URL is added to a black list which is updated throughout the computer system.

0019The electronic message content, for example a URL, may be identified as malicious by a first device or module that processes electronic messages to detect malware. Other first devices or modules in the system may process network traffic to detect malware. A central device or module may communicate with both the network traffic malware module and the electronic message malware module. In some embodiments, the central module may receive URLs detected to be malicious, may update a central URL blacklist based on the received URLs, and may transmit the updated URL blacklist to both the network traffic malware module and the electronic message malware module. This may cause a network malware module to examine more closely web traffic returning from requests to URLs passed in email, for example making it more likely that such web traffic was replayed in a virtual environment.

0020<figref idref="DRAWINGS">FIG. 1</figref> is block diagram of an exemplary system for detecting malicious electronic messages. The system of <figref idref="DRAWINGS">FIG. 1</figref> includes source device <b>105</b>, network <b>110</b> and malware detection system <b>100</b>. Malware detection system <b>100</b> includes firewall <b>120</b>, web malware detection device <b>130</b>, electronic message server <b>140</b>, electronic message malware detection device <b>150</b>, exchange server <b>160</b>, management server <b>170</b>, client device <b>182</b>, client device <b>84</b> and client device <b>186</b>. Though blocks within system <b>100</b> may be discussed herein as different devices, such as web malware detection <b>130</b> and electronic message malware detection <b>150</b>, blocks of system <b>100</b> may be implemented as modules within a single device or combination of devices.

0021Source device <b>105</b> may transmit electronic messages and content page content, such as web page content, to malware detection system <b>100</b> over network <b>110</b>. System <b>100</b> may receive network traffic content through firewall <b>120</b> and may receive electronic message content through electronic message server <b>140</b> via network <b>110</b>.

0022Network <b>110</b> may transmit electronic message, content page, and other content between devices connected to network <b>110</b>, including web malware detection system <b>130</b>, electronic message malware detection system <b>150</b>, and source device <b>105</b>. Network <b>110</b> may include one or more private networks, public networks, LANs, WANs, intranets, the Internet, and a combination of these networks.

0023Firewall <b>120</b> may be a device that consists of hardware and/or software that detects and prevents unauthorized network traffic from being received by or sent by client devices <b>182</b>, <b>184</b> and <b>186</b>. Firewall <b>120</b> may communicate with network <b>110</b> and web malware detection system <b>130</b>.

0024Web malware detection <b>130</b> may communicate with management server <b>170</b> and client devices <b>182</b>-<b>186</b>. Web malware detection <b>130</b> may operate to intercept network traffic and analyze intercepted traffic to determine whether the traffic is malware. The intercepted traffic may be copied by web malware detection <b>130</b> and analyzed using heuristics and other techniques. The heuristics may be used to identify portions of the network traffic as suspicious. Portions of traffic not identified as suspicious are ignored and passed through web malware detection <b>130</b>. The suspicious network traffic portions may be analyzed by replaying the traffic in a virtual environment. The replay may be monitored and used to identify malware content by web malware detection <b>130</b>. A system for re-playing intercepted traffic in a virtual environment using virtual components is described in U.S. patent application Ser. No. 12/359,252, entitled “Detecting Malicious Network Content Using Virtual Environment Components”, filed Jan. 23, 2009, the disclosure of which is incorporated herein by reference.

0025Electronic message server <b>140</b> may receive and send electronic messages between network <b>110</b> and electronic message malware detection <b>150</b>.

0026Electronic message malware detection <b>150</b> may communicate with exchange server <b>160</b>, management server <b>170</b>, and email server <b>140</b>, and may be implemented on one or more devices such a mail transfer agents (MTAs). Electronic message malware detection <b>150</b> may intercept electronic message traffic directed towards client devices <b>182</b>-<b>186</b>. Electronic message malware detection <b>150</b> may include logic which analyzes electronic messages transmitted to and from electronic message <b>140</b> to identify malicious content within the electronic message. Identifying malware may include identifying an electronic message as suspicious, analyzing suspicious electronic messages to identify a malicious message, and communicating the malicious content to management server <b>170</b> to inform the remainder of system <b>100</b>. Analyzing the suspicious electronic message may include replaying a portion of the electronic message in a virtual environment and monitoring the replay of the content. In some embodiments, content examined by electronic message malware detection <b>150</b> may include a URL detected within the body or header of an electronic message received by system <b>100</b>.

0027Exchange server <b>160</b> may transfer mail between client devices <b>182</b>-<b>186</b> and electronic message malware detection <b>150</b>. Management server <b>170</b> may receive malicious URL notifications, aggregate the received URLs, and update a black list maintained at management server <b>170</b>. The malicious URL notification may be received from system <b>150</b> or system <b>130</b>. Management server <b>170</b> may also transmit the black list of URLs to web malware detection systems and electronic message malware detection systems throughout system <b>100</b>.

0028Clients <b>182</b>, <b>184</b> and <b>186</b> may be any kind of device within a system <b>100</b> on which one or more users may execute programs to access network content such as a web page and transmit electronic messages such as an electronic message, instant message, or other electronic message.

0029<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram of an exemplary electronic message malware detection system. The system of <figref idref="DRAWINGS">FIG. 2</figref> includes network tap <b>210</b>, URL analyzer <b>220</b>, scheduler <b>230</b>, virtual environment component pool <b>240</b>, virtual environment <b>250</b> and URL database <b>260</b>. Network tap <b>210</b> may intercept electronic messages such as electronic message and instant messages transmitted between electronic message server <b>140</b> and exchange server <b>160</b>. Network tap <b>210</b> may make a copy of the electronic message to analyze within electronic message malware detection system <b>150</b>. Though electronic messages may include email as well as other types of messages, email will be discussed herein as merely an example.

0030URL analyzer <b>220</b> may detect URLs within a detected electronic message. Detecting a URL may include parsing the header and the body of an electronic message to identify a URL within the electronic message. Upon detecting a URL within a message, URL analyzer determines if the URL is suspicious and initiates an analysis of any suspicious URL. A URL may be suspicious if it does not appear in a list of acceptable URLs (a white list) and does not appear in a list of malware URLs (black list).

0031Upon detecting a suspicious URL, URL analyzer <b>220</b> provides the URL to scheduler <b>230</b>. Scheduler <b>230</b> receives suspicious URLs and retrieves virtual environment components from virtual environment component pool <b>240</b>. The virtual environment components may include components intended to replicate the actual environment at a client device intended to receive the electronic message. For example, the virtual environments may include a virtual operating system, virtual applications, and a virtual network intended to replicate those associated with a particular client device intended to receive the message. Scheduler <b>230</b> then provides the URL and the retrieved virtual environment components to a virtual environment <b>250</b> in order to replay the URL within a virtual environment.

0032Virtual environment <b>250</b> receives the suspicious URL and virtual environment components and replays the URL within a virtual environment having the virtual components. Replaying the URL may be similar to performing a “click” operation on the suspicious URL. Upon performing a click on the URL, a request is sent to the URL for content, and the network server associated with the URL provides content and a response to the request. The content received in response to the request is then processed by the virtual environment and the environment is monitored to determine if any undesirable behavior occurs. If any undesirable behavior occurs in response to loading content associated with the URL, the URL is determined to be malware and added to a local black list by electronic message malware detection system <b>150</b>. Undesirable behavior may unauthorized requests for data, sending or receiving data over a network, processing and/or storing data, changing a registry value, installing a file, executing a file, or other operations. The internal malware black list is transmitted to management server <b>170</b>.

0033URL database <b>260</b> includes black URL list <b>262</b> and white URL list <b>264</b>. URL analyzer may compare URLs detected in electronic messages to black URL list <b>262</b> to determine if there is a match. If there is a match, the URL is detected to be malware, and the electronic message may be blocked or the URL may be removed from the electronic message. If the URL is removed from the electronic message, an alert may be generated (e.g., within the message) indicating the URL has been removed and an administrator may be notified. If a detected URL matches a URL on the white URL list <b>264</b>, the URL is determined to be acceptable and no further action is taken. If a detected URL does not match a URL on black URL list <b>262</b> or white URL list <b>264</b>, the URL is identified as being suspicious and is processed in a virtual environment.

0034<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram of an exemplary management server. Management server <b>180</b> of <figref idref="DRAWINGS">FIG. 3</figref> includes URL aggregator <b>310</b>, URL black list <b>320</b>, and communication manager <b>330</b>. URL aggregator <b>310</b> aggregates received URLs and updates and stores URL black list <b>320</b>. URL black list <b>320</b> is a list of confirmed malicious URLs maintained by management server <b>180</b>. Communication manager <b>330</b> may receive URLs from electronic message malware detection systems and web malware detection systems within system <b>100</b>. Communication manager <b>330</b> may provide the URLs to URL aggregator <b>310</b> to aggregate the URLs and update URL black list <b>320</b> maintained on management server <b>180</b>. Communication manager <b>330</b> may also send the current URL black list to malware detection systems within system <b>100</b>.

0035<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart of an exemplary method for detecting malicious electronic messages. Though <figref idref="DRAWINGS">FIG. 4</figref> will be discussed in terms of an electronic message, other electronic messages, such as an instant message or other forms of communication, may be processed by the present technology.

0036An electronic message is received at step <b>405</b>. The electronic message may be received by electronic message malware detection system <b>150</b> via electronic message server <b>140</b>. The electronic message and/or an attachment to the message may be scanned to detect a URL at step <b>410</b>. The electronic message may be scanned by a URL analyzer module to detect a URL in the electronic message header, body or other portion of the electronic message. The attachment may be scanned to detect a URL within the attachment. For example, if the attachment is a word processor or spreadsheet document, the attachment may be scanned to detect a URL in text of the word processor document or within a cell of the spreadsheet.

0037Detected URLs may be transmitted to a malware detection system at step <b>415</b>. The malware detection system may be contained locally on electronic message malware detection system <b>150</b> or outside detection module <b>150</b>. For example, electronic message malware detection system <b>150</b> may transmit detected URLs to web malware detection system <b>130</b> to process the URL to determine if the URL is malicious. In some embodiments, a URL is simply stored locally at electronic message malware detection system <b>150</b> at step <b>415</b> for further processing.

0038A suspicious URL may be identified from the detected URLs at step <b>420</b>. A URL may be identified as suspicious if the URL does not match a black list of URLs or a white list of URLs maintained at electronic message malware detection system <b>150</b> (or accessible by detection module <b>150</b>). Identifying suspicious URLs is discussed in more detail below with respect to the method of <figref idref="DRAWINGS">FIG. 5</figref>.

0039Suspicious URLs are analyzed using virtual environment components to detect a malicious URL at step <b>425</b>. Analyzing a suspicious URL may include selecting virtual components such as a virtual operating system, virtual applications, and virtual network, populating and configuring a virtual environment with the virtual components, and processing the URL within the virtual environment. Processing the URL within the environment may include replaying the URL within the virtual environment by performing a “click” operation on the URL. The URL may be identified as malicious if content received in response to the click operation on the URL results in an undesirable behavior within the virtual environment. An undesirable behavior may include attempts to change an operating system setting or configuration, execute an executable file within the virtual environment, transmit undesirable data, or other actions. In some embodiments, an undesirable behavior may include an unexpected behavior. If no undesirable behavior occurs in response to clicking the URL, the URL is determined to be acceptable and is added to a white list.

0040A malware detection system may be updated based on the detected malware URL at step <b>430</b>. Updating may include communicating the malicious URL to other parts of a system. For example, electronic message malware detection system <b>150</b> may communicate one or more malicious URLs to management server <b>170</b>, and server <b>170</b> may communicate the URL via an updated black list to web malware detection systems and electronic message malware detection systems within system <b>100</b>. Updating a malware detection system is described in more detail below with respect to the method of <figref idref="DRAWINGS">FIG. 7</figref>.

0041One or more factors may affect how a URL is determined to be suspicious and/or processed to determine if it is associated with malware. In an embodiment, any URL detected in an email may be transmitted by electronic message malware detection <b>150</b> to web malware detection <b>130</b>. Upon detecting that content is being requested from the URL, for example in response to a user selection or “click” on the URL, the web malware detection <b>130</b> may increase the priority of the detected URL such that the URL is analyzed to determine if is suspicious and/or associated with malware. In this embodiment, the URL may not be processed by the web malware detection <b>130</b> until it is determined that content is actually being requested from the URL.

0042A large number of URLs may be detected by web malware detection <b>130</b> in network traffic travelling through firewall <b>120</b>. One or more detected URLs detected by web malware detection <b>130</b> may be assigned a priority for analysis. Higher prioritized URLs are analyzed to determine if they are suspicious or associated with malware before lower priority URLs. In some embodiments, URLs detected in email are provided a lower priority than those detected as part of network traffic by web malware detection <b>130</b>. The priority of a URL may be increased once it is determined to be present in both an email and network traffic (i.e., detected by both electronic message malware detection <b>150</b> and web malware detection <b>130</b>, in any order). The level of priority increase may depend on the resources available to process URLs. For example, the level of priority increase may be less if there are a small number of virtual environments or components available to process a suspicious URL. If there is a large number of virtual environments and/or virtual components available to process a URL, there may be a large level of priority increase. Hence, the priority of URLS to be processed by may adjusted in such a way to avoid degradation of the normal functioning of web malware detection <b>130</b> under heavy load, while allowing thorough examination of all email URLs where load permits

0043<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart of an exemplary method for identifying a suspicious URL. In some embodiments, the method of <figref idref="DRAWINGS">FIG. 5</figref> provides more detail for step <b>420</b> in the method of <figref idref="DRAWINGS">FIG. 4</figref>. Each detected URL in an electronic message is compared to a URL white list at step <b>505</b>. The URL white list may be maintained on electronic message malware detection system <b>150</b> and may include a list of acceptable URLs or URL domains. URLs that match the URL white list are ignored at step <b>510</b>. The URLs that match the white list are determined to not be malicious and therefore are allowed to pass through to their intended client device.

0044Detected URLs which are not on the white list are then compared to the URL black list at step <b>515</b>. URLs on the black list are known to be malicious and should not be passed through to a user associated with a client device. If a detected URL matches a URL on the black list, the URL is blocked and reported at step <b>520</b>, and thereby prevented from being provided to the recipient client device. A URL may be prevented from delivery by either blocking transmission of the entire electronic message, removing the URL from the electronic message, or in some other manner. URLs that do not match a URL on the white list or a URL on the black list are identified as suspicious URLs at step <b>526</b>. The remaining URLs are characterized as suspicious because it is unknown whether they are acceptable or malicious.

0045<figref idref="DRAWINGS">FIG. 6</figref> is a flowchart of an exemplary method for identifying malicious URLs. The method of <figref idref="DRAWINGS">FIG. 6</figref> provides more detail for step <b>525</b> of the method of <figref idref="DRAWINGS">FIG. 5</figref>. First, a suspicious URL is selected to analyze in a virtual environment at step <b>605</b>. Some URLs may be weighted with a higher priority to analyze. The higher priority URLs may be placed in a higher priority position in an analysis queue as opposed to lower priority URLs. A priority may be associated with a URL by a user, based on learning performed by the present system, or in some other manner. The priority may be associated with the URL domain, keywords in the URL, positioning within the electronic message for the URL, or other factors.

0046The present system may configure a virtual environment application, operating system, and network components at step <b>610</b>. These virtual components may be retrieved from a component pool by a scheduler. A URL may be analyzed in the virtual environment configured with the virtual components at step <b>615</b>. Analyzing the URL may include replaying the URL by performing a “click” operation on the URL within the virtual environment. Upon performing the click operation, an application may send a content request message to the URL and receive a response message in response to the URL request. For example, a network browser may be executed to provide the content received in response to the URL response received by the application. Actions performed within the virtual environment in response to receiving the URL content may be recorded and analyzed to determine if the URL is malicious.

0047A malicious URL may be identified at step <b>620</b>. An identification as a malicious URL may be based on actions or changes that occur when a suspicious URL is replayed in the virtual environment. Actions that may indicate a malicious URL include changing an operating system configuration, performing requests or trying to install or execute file, or other actions performed in response to retrieving content from the URL location.

0048<figref idref="DRAWINGS">FIG. 7</figref> is a flowchart of an exemplary method for updating a malware detection system. The method of <figref idref="DRAWINGS">FIG. 7</figref> provides more detail for step <b>430</b> of the method of <figref idref="DRAWINGS">FIG. 4</figref>. First, a management server receives a malicious URL detected by electronic message malware detection system at step <b>705</b>. The malicious URLs are then aggregated by the management server at step <b>710</b>. A URL black list is updated with the aggregated malicious URLs at step <b>715</b>. The management server may then transmit the updated URL black list to electronic message malware detection systems and web malware detection systems at step <b>720</b>. The transmission of the updated URL black list may be performed upon request, periodically, or upon occurrence of a particular event, such as when a URL black list has undergone a threshold number of changes.

0049In some applications of this technology, it may not be desired to fetch content from every URL seen in incoming electronic messages where such “clicks” may have undesired side effects on applications using the web (HTTP) as a communication protocol. Therefore, an alternative method can be used in such cases, in which all URLs received in electronic messages are forwarded to a web malware detection system, and are used to raise the probability of examining any particular piece of web content if it has previously been seen in electronic messages (e.g., email). Thus “targeted spear phishing” attacks in which malicious URLs are sent to particular email addresses in an effort to induce the recipient to click on the link will be examined by the malware detection system only in the event that the recipient does actually so click.

0050Since many URLs seen in electronic messages are also accessed via the web, the present invention also includes a dynamic method for setting the “email priority boost” used to enhance the priority of inspecting web content by noting the fraction of all the efforts of the web malware detection system devoted to examining URLs previously seen by the electronic message malware detection system. This “email priority boost” can be regulated to target a particular fraction of the virtual execution environments available on the web malware detection system, to avoid overloading the latter and causing loss of other web detection functionality, while still allowing complete examination of URLS seen in electronic messages where system load allows.

0051<figref idref="DRAWINGS">FIG. 8</figref> is a block diagram of an exemplary computing device. The computing device of <figref idref="DRAWINGS">FIG. 8</figref> may be used to implement one or more devices in the system <b>100</b> of <figref idref="DRAWINGS">FIG. 1</figref>, including but not limited to firewall <b>120</b>, web malware detection <b>130</b>, e-mail server <b>140</b>, e-mail malware detection <b>150</b>, management server <b>170</b>, exchange server <b>160</b>, or clients <b>182</b>-<b>186</b><figref idref="DRAWINGS">FIG. 8</figref> is a block diagram of an exemplary malicious network content detection device. In some embodiments, the method of <figref idref="DRAWINGS">FIG. 8</figref> provides more detail for malicious network content detection system <b>125</b> of <figref idref="DRAWINGS">FIG. 1</figref>. Malicious network content detection system <b>125</b> comprises at least one or more processors <b>805</b>, memory systems <b>810</b>, and storage systems <b>815</b>, each of which can be communicatively coupled with data bus <b>820</b>. In some embodiments, data bus <b>820</b> may be implemented as one or more data buses. Malicious network content detection system <b>125</b> may also comprise communication network interface <b>825</b>, input/output (I/O) interface <b>830</b>, and display interface <b>835</b>. Communication network interface <b>825</b> may be communicatively coupled with network <b>120</b> via communication medium <b>840</b>. In some embodiments, malicious network content detection system <b>125</b> may be communicatively coupled with a network tap, such as network tap <b>115</b>, which in turn may be communicatively coupled with network <b>120</b>. Bus <b>920</b> provides communications between communications network interface <b>825</b>, processor <b>805</b>, memory system <b>810</b>, storage system <b>815</b>, I/O interface <b>830</b>, and display interface <b>835</b>.

0052Communications network interface <b>825</b> may communicate with other digital devices (not shown) via communications medium <b>840</b>. Processor <b>905</b> executes instructions which may be stored on a processor-readable storage medium. Memory system <b>810</b> may store data permanently or temporarily. Some examples of memory system <b>810</b> include RAM and ROM. Storage system <b>815</b> also permanently or temporarily stores data. Some examples of storage system <b>815</b> are hard discs and disc drives. I/O interface <b>830</b> may include any device that can receive input and provide output to a user. I/O interface <b>830</b> may include, but is not limited to, a keyboard, a mouse, a touch screen, a keypad, a biosensor, a compact disc (CD) drive, a digital video disc (DVD) drive, an optical disk drive, or a floppy disk drive. Display interface <b>835</b> may include an interface configured to support a display, monitor, or screen. In some embodiments, malicious network content detection system <b>125</b> comprises a graphical user interface to be displayed to a user over a monitor in order to allow the user to control malicious network content detection system <b>125</b>.

0053The foregoing detailed description of the technology herein has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the technology to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. The described embodiments were chosen in order to best explain the principles of the technology and its practical application to thereby enable others skilled in the art to best utilize the technology in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the technology be defined by the claims appended hereto.