Malicious message analysis system

Embodiments of the disclosure relate to the field of cyber-security. More specifically, one embodiment of the disclosure relates to a system, apparatus and method configured to determine whether a message is associated with a malicious attack.

Over the last decade, malicious software has become a pervasive problem for Internet users as many networked resources include vulnerabilities that are subject to attack. For instance, over the past few years, an increasing number of vulnerabilities are being discovered in software that is loaded onto network devices. While some vulnerabilities continue to be addressed through software patches, prior to the release of such software patches, network devices will continue to be targeted for attack by malware, namely information such as computer code that attempts during execution to take advantage of a vulnerability in computer software by acquiring sensitive information or adversely influencing or attacking normal operations of the network device or the entire enterprise network.

Moreover, with the proliferation of the Internet and the reliance on electronic mail (email) as a means of communication, malware is capable of spreading more quickly and effecting a larger subset of the population than ever before. This is especially true because individual users and businesses can receive hundreds or even thousands of emails every day.

Conventional malware detection systems have been developed in an attempt to identify an email as malicious by (i) scanning content of the header and body of the email and (ii) comparing the scanned content with predetermined data patterns. These predetermined data patterns represent data that has previously been identified as being associated with malicious or suspicious activity. Hence, in response to detection of such data within the scanned content of the email, the conventional malware detection systems may block delivery of the email to the targeted recipient. No further analysis of the particular characteristics of the email message is considered as factors (and/or being used to derive the contextual information) in determining whether the email is associated with a malicious attack.

In fact, while some conventional antivirus programs may be configured to scan emails for malware, the methods currently in use may produce “false negative” results because an email may contain a malicious object that is part of a greater, multi-stage attack, but the object may not itself exhibit maliciousness during the scanning process. Consequently, the malicious object may be allowed to pass through to the end user. Also, updating of the scanning patterns is quite labor intensive, especially as more and more scan patterns are needed based on future detections of new types of malicious emails by the conventional malware detection system and perhaps other systems communicatively coupled to the conventional malware detection system. Using a scanning pattern is a reactive solution since these deterministic patterns are issued after analyzing the attack.

Accordingly, a need exists for an improved malicious message detection system, especially to detect potentially malicious suspicious email messages in a proactive manner.

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. 1A is an exemplary block diagram of a communication system deploying a Malicious Message Analysis (MMA) system via a network.

FIG. 1B is an alternative, exemplary block diagram of the MMA system of FIG. 1A .

FIG. 2 is an exemplary embodiment of a logical representation of the MMA system of FIG. 1A .

FIG. 3 is a flowchart of an exemplary method for analyzing context information based on a delivery protocol attributes.

FIG. 4 is a flowchart of an exemplary method for analyzing whether an email message is associated with a malicious attack considering delivery protocol attributes.

FIG. 5 is a flowchart of an exemplary method for updating a threat intelligence network based on a generated network-based blocking signature.

FIG. 6 is an exemplary embodiment of a mobile network device configured for performing the contextual analyses utilizing delivery protocol attributes.

Embodiments of the present disclosure generally relate to a Malicious Message Analysis (MMA) system configured to detect whether a message is associated with a malicious attack, and especially electronic mail (email) messages provided in accordance with any suitable delivery protocol (e.g., Simple Mail Transfer Protocol “SMTP”, Internet Message Access Protocol “IMAP”, etc.). Such detection may involve an analysis of content recovered from the header and/or body portions of the message, where the analysis is configured to detect one or more suspicious characteristics associated with the message. The suspicious characteristics (sometimes referred to as “delivery protocol attributes”) are provided to correlation logic, which considers the delivery protocol attributes in determining a likelihood (threat index) of the message being associated with a malicious attack (e.g., including malware, operating with malware, etc.).

According to one embodiment of the disclosure, the “message” analysis may be conducted by accessing meta information in the “FROM” header field to determine a source of the message. By way of a non-limiting example, in the event that the source is associated with a domain name, the MMA system may conduct an analysis of the domain name against known malicious domain names (hereinafter, “domain blacklist”) and, optionally, known benign domain names (“domain whitelist”). In the event that the domain name is not part of the domain blacklist (or the domain whitelist), the MMA system may initiate an attempt to communicate with a server associated with the domain name to confirm legitimacy of the sender (i.e. the sender of the message is accurately identified in the message). This communication may involve SMTP handshaking session to determine if the sender is found as being a member of the domain. The lack of sender verification may be represented as a delivery protocol attribute that is provided to the correlation logic and may operate as a strong indicator with respect to maliciousness of the message.

Hence, in some instances, the delivery protocol attributes may be outcome determinative. However, in other instances where the delivery protocol attributes are not outcome determinative. When an object, such as an attachment (e.g., file, document, etc.) or embedded content (e.g., URL, script, macro, etc.) is included with the message, a contextual analysis may be conducted on the delivery protocol attributes, along with attributes produced by one or more analyses on the object, in order to detect whether the message is malicious. The different types of analyses conducted on the object may include (i) behavioral analysis that is conducted by analyzing the behavior of a virtual machine during execution of the object, (ii) a static analysis in which the content of the object is analyzed without opening or execution of the object, and/or (iii) emulated processing of the object. Based on the combination of attributes and the correlation rules that denote malicious tendencies, the MMA system determines whether the message should be classified as malicious (i.e. the message is associated with a malicious attack).

With respect to the contextual analysis, it is contemplated that the attributes (results) from one type of analysis may be considered with attributes (results) from another type of analysis. More specifically, according to one embodiment of the disclosure, delivery protocol attributes may be combined with attributes produced by any one or more of the behavioral, static or emulation analyses to determine whether the message is associated with a malicious attack. It is contemplated that some of the attributes, namely (i) certain anomalous meta information pertaining to the email message itself, (ii) detected characteristics of the object (e.g., static analysis), and/or (iii) one or more monitored behaviors during a behavioral analysis of the object (e.g., the dynamic analysis), may be aggregated to form the context information. At least a portion of the context information is analyzed to determine whether the message is associated with a malicious attack.

Once maliciousness has been confirmed with regard to the message, an alert is generated. The alert (e.g., a type of messaging including text message or email message, a transmitted displayable image, or other types of information transmitted over a wired or wireless communication path) may provide a warning to a security administrator that an incoming message is malicious. In one embodiment, if maliciousness is found, the entire message may be blocked. Alternatively, if maliciousness is only found with respect to one aspect of a message, then that aspect may be blocked so that only non-malicious aspects of the message are passed through to an end user.

I. Terminology

In the following description, certain terminology is used to describe features of the invention.

In certain situations, both terms “logic,” “engine” and “component” are representative of hardware, firmware and/or software that is configured to perform one or more functions. As hardware, logic (or logic system or engine or component) may include circuitry having data processing or storage functionality. Examples of such circuitry may include, but are 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 logic system or engine or component) 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 “computerized” generally represents that any corresponding operations are conducted by hardware in combination with software and/or firmware.

The term “message” generally refers to information transmitted as information in a prescribed format and in accordance with a suitable delivery protocol (STMP, IMAP, POP, etc.), where each message may be in the form of one or more packets, frames, Session Initiation Protocol (SIP) or another messaging transmission, TCP, UDP, or IP-based transmissions, or any other series of bits having the prescribed format. Messages may include, by way of non-limiting example, email messages, text messages, and the like.

According to one embodiment, the term “malware” may be construed broadly as any code or activity that initiates a malicious attack and/or operations associated with anomalous or unwanted behavior. For instance, malware may correspond to a type of malicious computer code that executes an exploit to take advantage of a vulnerability, for example, to harm or co-opt operation of a network device or misappropriate, modify or delete data. In the alternative, malware may correspond to an exploit, namely information (e.g., executable code, data, command(s), etc.) that attempts to take advantage of a vulnerability in software and/or an action by a person gaining unauthorized access to one or more areas of a network device to cause the network device to experience undesirable or anomalous behaviors. The undesirable or anomalous behaviors may include a communication-based anomaly or an execution-based anomaly, which, for example, could (1) alter the functionality of a network device executing application software in an atypical manner (a file is opened by a first process where the file is configured to be opened by a second process and not the first process); (2) alter the functionality of the network device executing that application software without any malicious intent; and/or (3) provide unwanted functionality which may be generally acceptable in another context. Additionally, malware may be code that initiates unwanted behavior which may be, as one example, uploading a contact list from an endpoint device to cloud storage without receiving permission from the user.

In certain instances, the term “detected” is used herein to represent that there is a prescribed level of confidence (or probability) on the object or message being malicious as including malware and/or being associated with a malicious attack. Also, the terms “compare” or “comparison” generally mean determining if a match (e.g., a certain level of correlation) is achieved between two items where one of the items may include a particular pattern.

The term “network device” should be construed as any electronic device with the capability of connecting to a network. Such a network may be a public network such as the Internet or 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. Examples of a network device may include, but are not limited or restricted to, a laptop, a mobile phone, a tablet, a computer, standalone appliance, a router or other intermediary communication device, etc.

Finally, 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. Malicious Message Analysis Methodology

A. General Architecture of a Network Device Deploying a Malicious Message Analysis System

Referring to FIG. 1A , an exemplary block diagram of a communication system 102 that features a Malicious Message Analysis (MMA) system 100 that is communicatively coupled to a network 110 via an optional firewall 115 and/or an optional network interface 120 . Communications between a (mail) server device 105 and a client device 125 may be analyzed by the MMA system 100 . The MMA system 100 is communicatively coupled to a threat intelligence network 130 to receive an updated correlation rule sets 132 .

According to the embodiment illustrated in FIG. 1A , the MMA system 100 may be configured as a network device that is adapted to analyze messages that are part of network traffic, in particular electronic mail (email) messages, routed over the network 110 between the mail server device 105 and at least one client device 125 . The communication network 110 may include a public network such as the Internet, in which case an optional firewall 115 (represented by dashed lines) may be interposed on the communication path between the public network and the client device 125 . Alternatively, the network 110 may be a private network such as a wireless data telecommunication network, a wide area network, any type of local area network (e.g., LAN, WLAN, etc.), or a combination of networks.

As shown, the MMA system 100 may be communicatively coupled with the communication network 110 via the network interface 120 . In general, the network interface 120 operates as a data capturing device (sometimes referred to as a “tap” or “network tap”) that is configured to receive data propagating to/from the client device 125 and provide at least some of this data to the MMA system 100 . Alternatively, the MMA system 100 may be positioned in-line with client device 125 . For this embodiment, network interface 120 may be contained within the MMA system 100 operating as a communication interface 135 .

According to one embodiment of the disclosure, the network interface 120 is capable of receiving and routing network traffic to the MMA system 100 . The network interface 120 may provide the entire traffic or a certain subset of the network traffic, for example, such as an email message along with an object such as an attachment or embedded content.

As further shown in FIG. 1A , the MMA system 100 includes a communication interface 135 , an extraction engine 150 , a static analysis engine 180 , a dynamic analysis engine 210 , an emulation engine 230 , a classification engine 240 , and a reporting engine 260 . It should be appreciated that the extraction engine 150 , the static analysis engine 180 , the dynamic analysis engine 210 , the emulation engine 230 , the classification engine 240 , and the reporting engine 260 may each be separate and distinct components, although these engine (and any logic thereof) may also be implemented as a single software module or functionality residing on data processing circuitry such as a processor or a processor core.

In the interest of clarity, reference will now be made to an exemplary message 140 , which in one embodiment may refer to an email message. However, it should be understood that the message 140 may come in various forms and types as defined above.

In general, the email message 140 includes meta information 142 and optionally, one or more objects 144 (referred to as “object”). As discussed herein, the meta information 142 includes content associated with any of a plurality of header fields as well as the body of the email message 140 . Examples of the meta information 142 within the header fields may include, but are not limited or restricted to the following: (a) the “delivery-date”—the date the email message was delivered; (b) the “date”—the date the email message was sent; (c) the “message-ID”—the ID of the email; (d) the “X-Mailer”—information identifying the original messaging application and version; (e) the “from” field—message's source information/address; (f) the “to” field—message's destination information/address; and/or (g) the “subject”—the title and ancillary source information that may be used for alias mismatching. Similarly, the object 144 may include a file (e.g., Hypertext Markup Language “HTML” file, etc.), document, executable program macro, embedded script, or Uniform Resource Locator (URL) as defined herein.

Once the email message 140 is captured from the network traffic, it is communicated to the extraction logic 150 of the MMA system 100 via the communication interface 135 (e.g., one or more ports, network interface card, wireless transceiver, etc.). In some embodiments, as shown in FIG. 1A , the extraction logic 150 receives the email message 140 for parsing, prior to being routed to one or more analysis systems, such as static analysis engine 180 , the dynamic analysis engine 210 , and/or emulation engine 230 for example.

More specifically, the extraction logic 150 including parsing logic 155 that is configured to extract the meta information 142 and object 144 from the email message 140 . Thereafter, the meta information 142 of the email message 140 may be communicated to routing logic 160 and forwarded to the static analysis engine 180 . The object 144 may be communicated to routing logic 160 and forwarded to the static analysis engine 180 , dynamic analysis engine 210 , and/or the emulation engine 230 . A data store 170 may also be used to provide local storage for extraction analysis and rules, as well as operate as a local log.

As shown in FIG. 1A , in general terms, the static analysis engine 180 inspects the meta information 142 and object 144 for anomalies in characteristics such as formatting and patterns associated with known malware using, for example, heuristic, probabilistic, and/or machine-learning analysis schemes. Herein, the static analysis engine 180 includes a meta analyzer 182 and object analyzer 190 .

According to one embodiment of the disclosure, the meta analyzer 182 within the static analysis engine 180 may be configured to conduct one or more analyses on particular meta information 142 of the email message 140 (sometimes referred to as “message scanning”). As shown, the meta analyzer 182 features at least (network) header analysis logic 184 and format analysis logic 188 . The header analysis logic 184 is configured to determine the legitimacy of the source of the message 140 , legitimacy of the mail server (i.e. the sender of the message is accurately identified in the message 140 so as to not deceive the recipient as to origin). This validation by the network header analysis logic may be performed by making an outbound network communication. The format analysis logic 188 is configured to determine format violations in header fields based on corresponding message format specifications, and also has probabilistic, heuristic algorithm to determine the deviation of the header field from the normal headers delivering non-malicious attachments or URL. The Format analysis logic does not make any outbound network communication.

As an illustrative example, the header analysis logic 182 may access meta information associated with the “FROM” header field of the email message 140 , to determine its source. When the source is associated with a domain name (e.g., top-level domain and lower-level domain-abc.com), which may be represented as an email address (i.e. name@abc.com, name@abc.net, etc.) for example, the header analysis logic 184 may conduct a preliminary analysis of an identifier of the source against known malicious source identifiers. For instance, the preliminary analysis may include a comparison of the domain name associated with the source of the message 140 (e.g., a combination of the top-level and lower-level domains) against known malicious domain names (hereinafter, “domain blacklist”). Alternatively, the preliminary analysis may include a comparison between the email address identified in the email message 140 as the source against known malicious email addresses (hereinafter, “email blacklist”). As an option, the header analysis logic 184 may conduct a comparison of the domain name against known benign domain names (“domain whitelist”) or the email address against known benign email addresses (“email whitelist”). These source identifiers may be maintained in a data store as shown in FIG. 1B .

In the event that the domain name (or email address) is not part of the domain blacklist (or email blacklist) as well as the domain whitelist (or email whitelist) when utilized, the header analysis logic 184 may attempt to establish communications 186 with the mail server 105 associated with the source of the message 140 to confirm that the sender of the message 140 is correctly identified. The message exchange for such communications 186 may vary, depending on the delivery protocol for the message 140 (e.g., SMTP, IMAP, POP3, etc.).

As a non-limiting, illustrative example, in accordance with SMTP handshaking communication session, where the mail server 105 is a SMTP mail server, a DNS request message with the domain name at issue as a parameter is transmitted. This prompts a return of a DNS response message that will resolve the IP address of the mail server 105 responsible for message transmissions from the domain. Thereafter, the header analysis logic 184 may issue a command (e.g., HELO command) to the mail server 105 to initiate an SMTP session that is acknowledged by the mail server 105 (e.g., SMTP response code 250 that identifies the command has completed successfully).

A SMTP command (Mail From) message identifies to the mail server 105 that a new mail transition is starting, where a response code 250 is provided to identify that the address provided by the header analysis logic is accepted. Thereafter, a SMTP command (RCPT To) message is sent that identifies an email address of the intended recipient, which is selected as the source of message 140 . If the recipient is not found to be a member of the domain, which denotes a bounce-back condition, the header analysis logic 184 receives a SMTP response code 550 . The detection of this response code signifies that the source is not legitimate and a delivery protocol attribute is generated to denote that the message 140 was issued by a non-verified source and provided to the classification engine. An exemplary command-response flow of a SMTP handshaking communication session, which results in a “Recipient not found” attribute, is shown below:

220 smtp01-01.secureserver.net bizsmtp ESMTP server ready HELO [#.#.#.#] 250 smtp01-01.secureserver.net hello [#.#.#.#], pleased to meet you MAIL FROM: <address> 250 2.1.0<address> sender ok RCPT TO:<name@abc.com> 550 5.1.1<name@abc.com>Recipient not found. <http://x.co/irbounce> QUIT 221 2.0.0 smtp01-01.secureserver.net bizsmtp closing connection

Additionally, the meta analyzer 182 comprises format analysis logic 188 that compares formatting of the header fields in the message 140 to header field requirements in accordance with message formatting requirements for the delivery protocol. For instance, the absence of a “FROM” header field may be a format violation in accordance with the SMTP delivery protocol messaging specification. As another example, the absence of a “CC” field may be a format violation in accordance with IMAP delivery protocol messaging specification. The format violations (as well as the compliance) may be provided as delivery protocol attributes to the classification engine 240 . The format analysis logic 188 also has probabilistic, heuristic, machine learning logic (not separately depicted) to determine if the header fields are deviated from the normal messages. For instance, there is no email address in the “TO” field, “CC” field and there is an address in the “BCC” field. This characteristic is a deviation from the normal characteristics. Another instance can use-based logic (again, not separately depicted), which determines if the email server is different from the alias, which the sender's email may feature in the “FROM” field of the message.

According to one embodiment of the disclosure, the attributes from the analysis of the meta information 142 , such as the legitimacy of the source of the message 140 based on content associated with the “FROM” header field and/or formatting violations, output of the probabilistic, heuristic, machine learning logic detected for the message 140 in accordance with its delivery protocol for example, may be provided as delivery protocol attributes 205 to the classification engine 240 . Of course, other anomalous characteristics detected during analysis of the meta information 142 may be provided as part of the delivery attributes 205 .

Referring still to FIG. 1A , the object analyzer 190 of the static analysis engine 180 may also be configured to analyze the object 144 , where such analyses may include, but are not limited or restricted to, analysis of one or more characteristics (hereinafter “characteristic(s)”) associated with the object 144 , such as the object's name, object type, size, path, or the like. Additionally or in the alternative, the object analyzer 190 may analyze the object 144 by performing one or more checks. An example of one of these checks may include one or more signature checks, which may involve a comparison of (i) content of the object 144 and (ii) one or more pre-stored signatures associated with previously detected malware. In one embodiment, the check may include an analysis to detect for exploitation techniques, such as any malicious obfuscation, using for example, probabilistic, heuristic, and/or machine-learning logic. According to this embodiment of the disclosure, the extracted characteristic(s) may also be provided as static analysis (SA)-based attributes 206 to the classification engine 240 for subsequent contextual analysis.

It is envisioned that information associated with the object 144 may be further analyzed using the dynamic analysis engine 210 . Herein, the dynamic analysis engine 210 includes a virtual machine manager 215 , monitoring logic 218 , a data store 220 , and one or more virtual machines (VMs) illustrated at 225 1 - 225 N (N>1). The VMs 225 1 - 225 N are configured to perform in-depth dynamic (behavioral) analysis on the object 144 during processing in efforts to detect one or more anomalous behaviors. In general terms, the dynamic analysis engine 210 is adapted to process the object 144 within one or more VMs (e.g., VM 1 -VM N ) that simulate a run-time environment expected by the object 144 , where the behaviors of the VMs are monitored by the monitoring logic 218 and may be stored within the data store 220 .

In one embodiment, each of the one or more VMs 225 1 - 225 N within the dynamic analysis engine 210 may be configured with a software profile corresponding to a software image stored within the data store 220 that is communicatively coupled with the virtual machine manager 215 . Alternatively, the VMs (e.g., VM 1 -VM N ) may be configured according to a prevalent software configuration, software configuration used by a network device within a particular enterprise network (e.g., client device 125 ), or an environment that is associated with the object to be processed, including software such as a web browser application, PDF™ reader application, data processing application, or the like.

According to one embodiment, it is contemplated that the extraction logic 150 may further include processing circuitry (not shown) that is responsible for extracting or generating metadata contained within or otherwise associated with email message 140 from the parsing logic 155 . This metadata may be subsequently used by the virtual machine manager 215 for initial configuration of one or more VMs 225 1 - 225 N within the dynamic analysis engine 210 , which conducts run-time processing of at least some of the object 144 information associated with the email message 140 .

As further shown in FIG. 1A , the object 144 may be further analyzed using the emulation engine 230 , which is configured so as to enable the MMA system 100 (“host” system) to behave like any another computer system (“guest” system). It is envisioned that the emulation engine 230 may be configured so as to enable the host system to run any of various software, applications, versions and the like, designed for the guest system. More specifically, under control of request processing logic 235 , the emulation engine 230 may be configured so as to model hardware and software. As such, the emulation engine 230 may be divided into logic each corresponding roughly to the emulated computer's various systems, and as a result, the emulation engine 230 includes subsystems 232 . In one embodiment, the subsystems 232 include any of various processor emulator/simulators, a memory subsystem module, and/or various I/O devices emulators.

Furthermore, using the emulation engine 230 , certain artifacts that may be specific to (even unique with respect to) a type of known malware attack may be analyzed. For example, emulation engine 230 may also consider propagation mechanisms of an object 144 , to determine how instructions and/or behaviors associated with the object 144 communicate or navigate across and/or through a network, for example. According to this embodiment of the disclosure, the results of the emulation engine 230 may be provided as emulation analysis (EA)-based attributes 212 to the classification logic 240 for subsequent analysis.

It should be understood that some or all of the logic and engines set forth in FIG. 1A may be implemented as hardware or one or more software modules executed by the same processor or different processors. These different processors may be located within the same processor package (e.g., different processor cores) and/or located at remote or even geographically remote locations that are communicatively coupled (e.g., by a dedicated communication link) or a network. Also, some or all of the logic and engines set forth in FIG. 1A may be implemented as part of cloud services.

Referring now to FIG. 1B , an alternative embodiment of the MMA system 100 of FIG. 1A is shown. Once the email message 140 is captured from the network traffic, it may be communicated to a spam filter 151 , which may be configured to be substantially similar to the extraction logic 150 as shown in FIG. 1A . In some embodiments, as shown in FIG. 1B , the spam filter 151 includes filtering logic 156 , which is configured to specify a plurality of conditions consistent with malware, and to take appropriate actions thereto, which may involve, for example, further matching, blocking, and/or selective filtering. In one embodiment, after the email message 140 is analyzed by the spam filter 151 , an analysis is performed using the static analysis engine 180 .

In one embodiment, the static analysis engine 180 in FIG. 1B is substantially similar to the system of FIG. 1A , which illustrates a data store 192 to maintain, for example, a list of identifiers identifying a set of known malicious sources such as domains or email addresses that have invokes previously detected malicious attacks (e.g., black list) and a set of known sources that are considered reliable sources (e.g., white list). The list of identifiers may be used by header analysis logic 184 to determine the legitimacy of the sender of the message 140 .

Herein, the list of identifiers may be collected based on prior malware detection and periodically updated from a centralized server, or the threat intelligence network 130 , for example. If the email message 140 is identified as one of the matched identifiers in the list, the email message 140 may be classified immediately using the classification engine 240 , as either malware or non-malware, without having to perform a further analysis. It is contemplated that the data store 192 may further include message formatting requirements, heuristic probabilistic, machine learning logic (e.g., computer instructions) for one or more delivery protocols (e.g., SMTP, IMAP, POP3, etc.) for use by format analysis logic 188 to determine delivery protocol attributes 205 associated with formatting anomalies and/or determine the deviation of the headers from the normal header.

In one embodiment, based on the attributes 205 , 206 , 208 and/or 212 , certain signatures such as blocking signatures may be generated and stored using the signature generation logic 266 . In the event that further analysis is required, data associated with the email message 140 may be analyzed by the dynamic analysis engine 210 , and/or the emulation engine 230 , as discussed herein.

Referring to FIGS. 1A-1B , it is important to note that the various analyses as discussed herein may be performed in a concurrent (i.e., at same time or in an overlapping manner) or serial fashion, without limitation. As such, the various analyses do not each need to be complete prior to being analyzed by any other subsystem. For example, the dynamic analysis may be performed prior to, or during the static analysis. Thus, it is envisioned that the context information, namely delivery protocol attributes from the message analysis (header and/or body of email message 140 ) along with attributes associated with the static analysis (of object 144 ), dynamic analysis (of object 144 ), and/or emulation (of object 144 ), may be analyzed.

For example, once an email message 140 is received by the MMA system 100 , the meta information 142 associated with the message 140 may be analyzed by the meta analyzer 182 with the static analysis engine 180 . In response to detecting anomalous characteristics associated with the message 140 (e.g. sender incorrectly identified in the message 140 , formatting irregularities, etc.), the meta analyzer 180 provides delivery protocol attributes 205 to the correlation logic 242 of the classification engine 240 . The delivery protocol attribute 205 may be considered in the classification of the message 140 as malicious or non-malicious when the expanded correlation rule set 132 includes rules that take the presence or absence of certain delivery protocol attributes 205 into account. As such, an alert 280 may be generated by the reporting engine 260 based, at least in part, on the delivery protocol attributes 205 .

As another example, once an email message 140 including the object is received by the MMA system 100 , the object 144 may be analyzed by the dynamic analysis engine 210 . In one embodiment, a portion of the DA-based attributes 208 from the dynamic analysis engine 210 may be determined, by the classification engine 240 , to be dispositive with respect to a finding of maliciousness. As such, the alert 280 may be generated by the reporting engine 260 based on the results of the dynamic analysis engine 210 alone.

However, in the event that the portion of the DA-based attributes 208 is not dispositive, in accordance with expanded correlation rule set 132 , the classification engine 240 may determine whether the email message 140 is associated with a malicious attack based on the presence (or even absence) of one or more delivery protocol attributes 205 . The combination of these attributes corresponds to context information, where a portion of the context information may be analyzed to determine whether the email message 140 is associated with a malicious attack.

Of course, it is envisioned that none, some or all of these analyses may be operating concurrently where, during the dynamic analysis, some of the delivery protocol attributes 205 or SA-based attributes 206 may be provided.

B. General Classification Methodology with Respect to the Plurality of Analyses

Referring back to FIG. 1A , according to one embodiment of the disclosure, the results from each of the analyses are routed to the classification engine 240 for further processing. More specifically, the delivery protocol attributes 205 , the SA-based attributes 206 , the DA-based attributes 208 and/or the EA-based attributes 212 are communicated to the classification engine 240 . It is envisioned that the correlation logic 242 , operating in accordance with the expanded correlation rule set 132 , may assign a threat index value to particular attributes and/or particular combinations of attributes (from the same or different analyses). The threat index values may be used to determine a threat index for the email message 140 , which indicates whether or not the message 140 is malicious.

As briefly described above, the classification engine 240 determines a threat index associated with the email message 140 that is under analysis. The threat index may be used to represent, at least in part, (i) a score that corresponds to a likelihood of the message 140 being malicious (e.g., message 140 includes malware or is part of a malicious attack); (ii) a policy violation caused by the receipt of the message 140 (or the object 144 provided with the message 140 ); or (iii) a severity of a potential malicious attack by the message 140 . Hence, when the threat index exceeds a prescribed threshold value, the message 140 is considered to be malicious.

More specifically, the classification engine 240 includes correlation logic 242 that operates in accordance with the expanded correlation rule set 132 . The correlation logic 242 is configured to receive attributes 205 and/or 206 , 208 or 212 . The correlation logic 242 attempts to correlate some or all of the attributes 205 , 206 , 208 and/or 212 associated with the email message 140 in accordance with the expanded correlation rule set 132 , which is stored in correlation rules data store 245 . For this embodiment, the correlation determines what particular attributes and/or combination of attributes, including the delivery protocol attributes 205 , have been collectively detected by the static analysis engine 180 , dynamic analysis engine 210 and/or emulation engine 230 in accordance with the attribute patterns set forth in the expanded correlation rule set 132 , which may be preloaded at manufacturer and periodically or a periodically updated. By way of non-limiting example, the expanded correlation rule set 132 may cause the index assignment logic 243 and the weighting logic 244 of the correlation logic 242 to set the threat index values and corresponding weighting for a portion of the context information (e.g., selective attributes), which is used by the classification logic 250 to calculate a threat index 255, which denotes a likelihood of the email message 140 being associated with a malicious attack.

According to one embodiment of the disclosure, each attribute and/or combination of attributes may be associated with a threat index value (and optionally a weighting), where the summation of these threat index values is used to determine maliciousness. An illustrative example of the threat index 255 computed in accordance with a particular correlation rule (attribute pattern) is shown in equation (1):

Threat index 255 =Σ MI [W 1 (delivery protocol attribute_1)+W 2 (EA-based attribute_2)+W 3 (delivery protocol attribute_3& DA-based attribute_4& SA-based attribute_6)+W 4 (delivery protocol attribute_5& no SA-based attribute_6)]  (1)

According to this illustrative example, the threat index 255 may be computed by a combination of threat index values associated with any or all of the following: particular attributes (delivery protocol attributes_1, EA-based attribute_2) of the context information, combinations of attributes that are present (delivery protocol attribute_3 & DA-based attribute_4), and/or combinations of attributes where some attributes are absent (delivery protocol attribute_5 & no SA-based attribute_6). These particular attributes (e.g., attribute_1 to attribute_6) may be from different analyses and only some (not all) of the attributes from these different analyses are used to determine the threat index 255.

Optionally, the weighting factors (W 1 , W 2 , . . . ) may be used to place higher probative likelihood of maliciousness for certain attributes or even combinations of attributes. Consequently, each of the weighting factors (W 1 . . . W N ) may be tailored specifically for certain types of malware campaigns, analysis system result, or the like, without limitation. It is envisioned that in one embodiment, no weighting factors are included when determining the threat index 255.

Of course, as another illustrative example, the threat index 255 may be an aggregation of attribute scores across a plurality of analyses, as set forth below:

Threat index 255 =Σ MI [(Delivery Protocol attributes 205 )+(SA-based attributes 206 )+(DA-based attributes 208 )+(EA-based attributes 212 )]  (2)

As set forth in equation (2), the threat index 255 may be computed by a threat index based on a combination of threat index values associated with particular attributes of the context information formed by portions of the delivery protocol attributes 205 , SA-based attributes 206 , DA-based attributes 208 , and/or the EA-based attributes 212 . Optionally, the threat index may be weighted by weighting logic 244 .

The combination of threat index values as discussed herein is tailored to specific attributes to determine maliciousness with respect to the email message 140 , thereby reducing false negative results as well as false positives. For example, an email message featuring an incorrectly identified source in the “FROM” header field (attribute_3—delivery protocol) that is observed with ‘callback’ (i.e., attempt to send an outbound communication) to an outside source (attribute_4—DA-based) and an attachment less than 10 kilobytes (attribute_6—SA-based) may be more indicative of an advanced malicous attack, as compared to considering only the attachment size (attribute_6) and the callback behavior (attribute_4), which may produce a false negative result. By combining of context information associated with different analysis types, the APT attack may be detected more accurately, for example. Similarly, the presence of a deployment attribute that identifies that the source is correctly identified in the message (attribute_7), combined with the attachment size (attribute_6) and the callback behavior (attribute_4) may reduce the threat index to avoid a false positive result.

Once the threat index 255 has been computed, it is compared with a predetermined threshold value that is used to determine whether or not an alert should be generated. In one embodiment, the predetermined threshold value may represent, perhaps numerically, an aggregate value based on a consideration of, for example, certain incidences, feature sets, vulnerabilities, and/or attack signatures specific to any of various malware attacks. However, it is envisioned that the predetermined threshold value may be variable, depending on any of various factors, including by way of non-limiting example, the geographical or industry-type information regarding the most recent, and/or previously targeted parties. Accordingly, it should be understood that the predetermined threshold value might vary for different types of attacks.

Alternatively, in lieu of reliance on a score as the threat index to determine whether an email message is malicious, the classification engine 240 includes correlation logic 242 that operates in accordance with the expanded correlation rule set 132 that identify context information of known maliciousness and of known non-maliciousness. Hence, unlike a scoring mechanism, the matching of certain attributes recovered from different types of analyses to the malicious (or non-malicious) context provided by the correlation rules may be used to determine whether or not the email message 140 is associated with a malicious attack. Accordingly, in some embodiments, the classification may be based on a non-quantified assessment of threat risk based on the analysis results.

For example, a file (object) 144 is part of an attachment for an incoming email message 140 under analysis. The object analyzer 190 determines that the file 144 is obfuscated (characteristic_1) while the meta analyzer 182 determines that the source of the email message 140 differs from the source enumerated in the email message (sender verification failed). Furthermore, the dynamic analysis engine 210 determines that an HTTP GET request is generated by the file 144 (behavior_1). In accordance with the context information (characteristic_1, sender verification failed, behavior_1) matching malicious content as provided by a correlation rule within the expanded correlation rule set 132 that identifies a collection of context information found to be malicious, the file 144 (and hence the email message 140 ) is determined to be associated with a malicious attack.

In the event that the threat index 255 meets or exceeds the predetermined threshold value (or the comparison of context denotes maliciousness), the alert generation logic 265 of the reporting engine 260 is signaled to generate the alert 280 . The alert 280 (e.g., an email message, text message, display screen image, etc.) may be routed to a network device utilized by a network administrator or a threat intelligence network 130 , for example. The reporting engine 260 may be configured so as to store the results from the analysis conducted by the classification engine 240 in the data store 270 for future reference.

Referring now to FIG. 2 , an exemplary embodiment of a logical representation of the MMA system 100 of FIGS. 1A-1B is shown. In one embodiment, a network appliance 200 includes a housing 201 , which is made entirely or partially of a rigid material (e.g., hardened plastic, metal, glass, composite or any combination thereof) that protect circuitry within the housing 201 , namely one or more processors 285 that are coupled to communication interface logic 286 via a first transmission medium 287 . Communication interface logic 286 enables communications with other MMA systems and/or the threat intelligence network 130 of FIG. 1A , for example. According to one embodiment of the disclosure, communication interface logic 286 may be implemented as a physical interface including one or more ports for wired connectors. Additionally, or in the alternative, communication interface logic 286 may be implemented with one or more radio units for supporting wireless communications with other electronic devices.

Processor(s) 285 may further be coupled to persistent storage 290 via a second transmission medium 288 . According to one embodiment of the disclosure, persistent storage 290 may include the MMA system 100 , which in one embodiment includes the extraction logic 150 , the static analysis engine 180 , the dynamic analysis engine 210 , the emulation engine 230 , the classification engine 240 , and the reporting engine 260 as described above. It is envisioned that one or more of these systems could be implemented externally from the MMA system 100 without extending beyond the spirit and scope of the present disclosure. For instance, the dynamic analysis engine 210 may be located within cloud services.

Referring now to FIG. 3 , a flowchart of an exemplary method for providing warning of a potential email-based attack on a system or device based on a real-time analysis. In block 301 , an email message is received and routed to the meta analyzer within the exemplary MMA system 100 . At block 302 , meta information is extracted and routed to the static analysis engine for further analysis. At block 303 , static analysis is performed on the meta information within one or more header fields of the email message.

For example, using the meta analyzer within the static analysis engine, a determination may be made as to the legitimacy of the source of the email message, which may include an attempted handshake scheme being conducted to determine if the source is identified by the source address included in the email message. A lack of legitimacy, namely a lack of IP address verification (IP address redirection) and/or any alias mismatching (e.g., source identified in the subject field is inconsistent with the actual source) provides a strong indication that the email message is malicious.

At block 304 , a determination is made with respect to whether further analysis is required. For instance, meta information of the email message may be compared with previously known email message attacks, malicious attribute sets, attack signatures, etc. so as to determine maliciousness. For example, the occurrence of a known alias mismatch, a particular subject line, or certain body content of an email message may indicate to some level of probability, often well less than 100%, that the email message includes a certain exploit or exhibits certain elements associated with malware.

In one embodiment, at block 305 , the classification engine may be configured to take certain action, including for example, generating an alert if the probability exceeds a prescribed value, for example. In one embodiment, the classification engine may be configured so as to inform end users and update the threat intelligence network. Alternatively, at block 306 , further analysis may be required with regard to other aspects of the email message, for example, analysis of an object through static analysis, dynamic analysis and/or emulation to make a final decision with respect to maliciousness.

Referring now to FIG. 4 , a flowchart of an exemplary method for conducting one or more analyses on an object that is part of the email message is shown. At block 402 , the email message is analyzed so as to determine whether any objects are present therein. At block 403 , if there is no object, the classification engine may rely on the analysis conducted on the context information associated with meta information within the object to determine maliciousness.

Additionally, or in the alternative, in the event that an object is present, further analysis performed as shown in blocks 405 - 407 . For example, the object (or copies thereof) may be routed to the static analysis engine, the dynamic analysis engine, and/or the emulation engine. Certain attributes from the static analysis engine (characteristics of a file), dynamic analysis engine (behaviors of a file) and/or emulation engine (emulated results), along with delivery protocol attributes associated with the message analysis (block 404 ), may be combined together and classified based on a presence of these attributes as part of the context information. When classified, as an optional feature, the threat index may be generated based on selected delivery protocol attributes as discussed herein. More specifically, at block 408 , a combination of attributes provided by a plurality of analyses (e.g., delivery protocol attributes, SA-based attributes, DA-based attributes, and/or EA-based attributes) is determined by the correlation logic.

At block 409 , in accordance with an expanded correlation rule set, the correlation logic assists the classification logic in a determination as to whether the email message is malicious. The determination may be based, at least in part, on one or more delivery protocol attributes. More specifically, at block 410 , upon determining that the email message is malicious, the classification engine may cause the reporting engine to issue an alert (block 410 ) and commence a signature generation operation as illustrated in FIG. 5 (block 411 ). Otherwise, the analysis ends (block 412 ).

C. Generation of Blocking Signatures

It is envisioned that in order to generate scores from the context information 142 , some of the embodiments will require an outbound connection. For example, to determine if a particular mail server exists, a DNS query to the mail server will need to be performed. Based on the response of the DNS, a determination can be made with respect to the existence of the mail server. Similarly, to determine if an email message 140 is valid, an SMTP handshake must be performed with respect to the SMTP server. In some deployment it can happen that the outbound SMTP communication to validate sendermight not be possible due to firewall policy.

Reference is now made to FIG. 5 , where, at block 501 , once an email message is declared as being malicious, the email message is uploaded to the threat intelligence network 130 of FIGS. 1A & 1B , as shown in block 502 . At block 503 , the context information of the email message is analyzed to determine if the various fields (e.g., meta fields), for example, are sufficiently specific (or even unique) in nature to serve as a signature (strong indicator) for the detected malicious attack. At block 504 , a query is presented to determine whether the context information may be used to generate a signature. At block 505 , a signature may be generated. In one embodiment, a deterministic, exploit-specific, signature may be generated, however almost any other methodology may be used so as to quickly (and without detailed analysis) identify and classify potential malware samples as malware. In one embodiment, the signature may comprise descriptions (indicators) of malware families. At block 506 , the signature is uploaded to the threat intelligence network. Finally, at block 507 , the signature is deployed to “users”, for example those individuals and entities that have implemented the MMA system and/or have access to the threat intelligence network, e.g., through a subscription service. Since these signatures may consist of meta-fields from the malicious emails, these will classify the email as malicious. Also, if the signature consists of an identifier for the malicious “senders”, it will be added to the black list discussed earlier herein.

D. Exemplary Alert

Referring to FIG. 6 , an exemplary embodiment of a mobile network device 600 (e.g., smartphone, tablet, laptop computer, netbook, etc.) configured for performing the contextual analyses utilizing delivery protocol attributes as described above is shown. Herein, the mobile network device 600 includes a display screen 605 and a housing 610 that encases one or more processors (“processor(s)”) 620 , memory 630 , as well as one or more receiver and/or transmitter (e.g. transceiver) 640 communicatively coupled to an antenna 645 . Herein, the memory 630 includes a security agent 650 .

Upon execution by the processor(s) 620 , the security agent 650 (executable software application) conducts an analysis on the header and/or body of an incoming email message 660 received by the transceiver 640 of the mobile network device 620 . Herein, the security agent 650 conducts an analysis of certain fields of the email message 660 , such as certain fields of the header as described above, which may necessitate communications with other network devices (e.g., mail server). Such analysis enables the security agent to produce delivery protocol attributes, which are used in an analysis conducted by a classification engine 670 in determining whether the email message 660 is malicious. Additional static and/or dynamic analysis of an object that is attached to the email message 660 and/or emulation operations associated with object 660 may be used to obtain further attributes that identify anomalous characteristic, behaviors or emulated features, where some of these attributes may be considered in the classification of the email message 660 . The delivery attributes and other attributes may be stored in a log that is allocated within the memory 630 .

Herein, the memory 630 may further include the classification engine 670 and the reporting engine 680 that operate in combination with the security agent 650 in a manner similar to classification engine 240 and reporting engine 260 of FIGS. 1A-1B and 2 as described above.

In one embodiment, an exemplary alert 690 (e.g., an object, text message, display screen image, etc.) is communicated to security administrators and/or may be displayed for viewing on the mobile network device 600 . For example, the exemplary alert 690 may indicate the urgency in handling one or more predicted attacks based on the maliciousness of the suspect object. Furthermore, the exemplary alert 690 may include instructions so as to prevent one or more predicted malware attacks. The exemplary alert 690 may also include information with respect to the origination of the potential attack, along with suspicious behavior that might confirm the attack with respect to a potential target. In one embodiment, the exemplary alert 690 may include index values represented as scores and/or percentages based on the various analyses and/or the combination of detected behaviors, characteristics and/or emulated results that caused the alert 690 , as discussed herein.

In the foregoing description, the invention is described with reference to specific exemplary embodiments thereof. However, it will 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.