Patent Description:
Command and control is a post-exploitation tactic that allows attackers to maintain persistence, communicate with infected hosts, exfiltrate data and issue commands. Once a host is infected, malware establishes a command and control channel to the attacker. To avoid detection, agents often lie dormant for long periods, periodically communicating with the server for further instructions. These intermittent communications are referred to as malware beacons.

Detecting the presence of malware beacons in network data is difficult for a number of reasons. For example, the check-in interval for implanted agents varies and most command and control systems have built-in techniques to avoid detection such as for example by adding random jitter to the callback time. As another example, malware beacons are often disguised as network data by imitating normal communications such as DNS or HTTP requests. Document "<NPL>) relates to an Intrusion Detection Systems or IDS, which is a device or a software application that monitors a network for malicious activity or policy violations. Document "<NPL>) discloses the use of Fingerprints by the random forest classifier to predict which flowsets contain traffic generated by one of the malware types.

Accordingly there is provided a method, a system, and a computer program as detailed in the claims that follow.

Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present application and in which:.

Like reference numerals are used in the drawings to denote like elements and features.

<FIG> is a high-level block diagram of a system <NUM> for machine learning based malware detection according to an embodiment. The system <NUM> includes a server computer system <NUM> and a data store <NUM>.

The data store <NUM> may include various data records. At least some of the data records may include network data. The network data may include a training set of network data that includes benign network data and malware network data. As will be described, the benign network data may include network data known to be benign, that is, known to not include malware. The malware network data may include network data that is known to be malware. Each network log may be referred to as a flow event.

In one or more embodiments, the network data stored in the data store <NUM> may include network logs where each network log is a flow event between a specific destination and a specific remote endpoint. Each network log may include a timestamp, a source internet protocol (IP) address, a destination IP address, a source port, a destination port, etc. The network log may additionally include data transmission information such as for example packet sizes, bytes up/down, etc..

The data store <NUM> may additionally maintain one or more whitelists that include IP addresses known to be trusted and may maintain one or more blacklists that include IP addresses known to be malware. As will be described, the one or more whitelists may be consulted such that any flow events associated with a whitelisted IP address may not be subject to classification. Similarly, the one or more blacklists may be consulted such that any flow events associated with a blacklisted IP address may be blocked or may cause an alert to be raised.

The data store <NUM> may only store network data that has occurred within a threshold time period. For example, the data store <NUM> may only store network data for the last seven (<NUM>) days and as such may drop, erase or otherwise delete network data that is more than seven (<NUM>) days old.

In one or more embodiments, the system <NUM> includes a malware engine <NUM>, a feature extraction engine <NUM>, and a machine learning engine <NUM>. The malware engine <NUM> and the feature extraction engine <NUM> are in communication with the server computer system <NUM>. The malware engine <NUM> may log network data locally and may export the logged network data to the data store <NUM> via the server computer system <NUM>. The machine learning engine <NUM> is in communication with the feature extraction engine <NUM> and the server computer system <NUM>. The malware engine <NUM>, the feature extraction engine <NUM> and the machine learning engine <NUM> may be discrete computing devices in different environments.

The malware engine <NUM> may be configured to generate malware network data that may be used to train the machine learning engine <NUM>. The malware network data may include malware beacons communicated between a source and destination pair. In one or more embodiments, the malware engine may include a virtual server such as a training malware server and one or more virtual computing devices and communication between the virtual server and the one or more virtual computing devices may be logged as malware network data.

The malware engine <NUM> may be configured to generate the malware network data by, for example, varying the beacon interval, jitter amount, data channels, etc. and in this manner a wide range of beacon obfuscation is obtained. The malware network data may include an IP address of the training malware server and this may be used to train the machine learning engine <NUM>. For example, any network logs that include the IP address of the training malware server may be identified as malware network data.

As will be described, the malware network data generated by the malware engine <NUM> may be stored in the data store <NUM> and used to train the machine learning engine <NUM>.

The feature extraction engine <NUM> is configured to analyze network data received from the data store <NUM> to generate a set of dyads for each source-destination pair in the network data. To generate the set of dyads for each source-destination pair in the network data, the feature extraction engine <NUM> may analyze the network data to categorize the network data by source-destination pair. For each source-destination pair, the set of dyads may include a number of flow events, a mean of bytes down, a standard deviation of bytes down, a mean of bytes up, a standard deviation of bytes up, a communication interval mean, a communication interval standard deviation, a communication interval skew, a communication interval kurtosis, a number of local end points that made a connection to the destination and a number of remote end points that the local endpoint connected to.

The number of flow events may include a count of how many flow events occur in the network data for the source-destination pair. Since each network log is a flow event, the feature extraction engine <NUM> may count the number of network logs for the source-destination pair in the network data and this may determine the number of flow events per source-destination pair.

The mean of bytes down for each source-destination pair may be generated by calculating an average size of bytes down for the source-destination pair for all flow events in the network data for the source-destination pair.

The standard deviation of bytes down for each source-destination pair may be generated by calculating a standard deviation of bytes down for the source-destination pair for all flow events in the network data for the source-destination pair.

The mean of bytes up for each source-destination pair may be generated by calculating an average size of bytes up for the source-destination pair for all flow events in the network data for the source-destination pair.

The standard deviation of bytes up for each source-destination pair may be generated by calculating a standard deviation of bytes up for the source-destination pair for all flow events in the network data for the source-destination pair.

The communication interval mean may include a mean of seconds between flow events and may be generated by calculating an average of seconds between flow events. It will be appreciated that seconds between flow events may be an amount of time between adjacent flow events.

The communication interval standard deviation may include a standard deviation of seconds between flow events and may be generated by calculating a standard deviation of seconds between flow events.

The communication interval skew may include a metric indicating how skewed toward one end a distribution is.

The communication interval kurtosis may include a metric indicating a tailedness of a probability distribution. The communication interval kurtosis may be generated by determining a measure of the combined weight of the distribution's tail relative to the center of the distribution.

The number of local end points that made a connection to the destination may include a count of local end points that had a flow event with the destination in the network data.

The number of remote end points that the local endpoint connected to may include a count of remote end points that had one or more flow events with the source in the network data.

The machine learning engine <NUM> may include or utilize one or more machine learning models. For example, the machine learning engine <NUM> may be a classifier such as for example a Random Forest classifier that may be trained to classify network data as one of malware network data of benign network data. Other machine learning methods that may be used include Support Vector Machines, decision-tree based boosting methods such as for example AdaBoost (TM) and XGBoost (TM).

In one or more embodiments, the set of dyads generated by the feature extraction engine using the training network data may be used to train the machine learning engine <NUM> for malware detection.

<FIG> is a flowchart showing operations performed by the server computer system <NUM> for training the machine learning engine for malware detection according to an embodiment. The operations may be included in a method <NUM> which may be performed by the server computer system <NUM>. For example, computer-executable instructions stored in memory of the server computer system <NUM> may, when executed by the processor of the server computer system, configure the server computer system <NUM> to perform the method <NUM> or a portion thereof. It will be appreciated that the server computer system <NUM> may offload at least some of the operations to the malware engine <NUM>, the feature extraction engine <NUM> and/or the machine learning engine <NUM>.

The method <NUM> includes obtaining a training set of network data that includes benign network data and malware network data (step <NUM>).

In one or more embodiments, the server computer system <NUM> may obtain the training set of network data from the data store <NUM>. As mentioned, the malware network data may be generated by the malware engine <NUM>. The benign network data includes network data that is known to be benign and the malware network data includes network data that is known to be malware.

<FIG> is a graph showing data transmissions in malware network data used for training the machine learning engine.

<FIG> is a graph showing data transmissions in benign network data used for training the machine learning engine.

Comparing <FIG>, it can be seen that the malware network data includes packet sizes that are very consistent and the benign network data has inconsistent data patterns and packet sizes.

<FIG> is a graph showing communication intervals in malware network data used for training the machine learning engine.

<FIG> is a graph showing communication intervals in benign network data used for training the machine learning engine.

Comparing <FIG>, it can be seen that the malware network data includes consistent and regular communication intervals and the benign network data includes communication intervals that include long periods of inactivity and has a large number of communication intervals close to zero.

In one or more embodiments, the malware network data may include a communication interval skew that is more consistent than the benign network data and/or may include a communication interval kurtosis that is more evenly clustered than the benign network data.

The method <NUM> includes engaging a feature extraction engine to generate a set of dyads for each source-destination pair in the training set of network data (step <NUM>).

As mentioned, to generate the set of dyads for each source-destination pair in the network data, the feature extraction engine <NUM> may analyze the network data to categorize the network data by source-destination pair. For each source-destination pair, the set of dyads may include a number of flow events, a mean of bytes down, a standard deviation of bytes down, a mean of bytes up, a standard deviation of bytes up, a communication interval mean, a communication interval standard deviation, a communication interval skew, a communication interval kurtosis, a number of local end points that made a connection to the destination and a number of remote end points that the local endpoint connected to.

The method <NUM> includes training, using the set of dyads, a machine learning engine to differentiate between the benign network data and the malware network data (step <NUM>).

The set of dyads are fed into the machine learning engine and are used to train the machine learning engine to classify network data as benign network data or malware network data. Once trained, the machine learning engine may classify network data as one of benign network data or malware network data.

In embodiments where the machine learning engine <NUM> includes a Random Forest classifier, the set of dyads may be labelled with a zero (<NUM>) indicating benign network data or may be labelled with a one (<NUM>) indicating malware network data. Further, a package function may be used to fit the model to the data. For example, a fitting method may be used for each decision tree associated with the Random Forest classifier and the fitting method may include selecting a feature and a numerical value such that when the network data is split based on the feature. In this manner, the purity of each split data chunk is maximized. This may be repeated multiple times for each decision tree and as such the classifier is trained for the prediction task.

<FIG> is a flowchart showing operations performed for machine learning based malware detection according to an embodiment. The operations may be included in a method <NUM> which may be performed by the server computer system <NUM>. For example, computer-executable instructions stored in memory of the server computer system <NUM> may, when executed by the processor of the server computer system, configure the server computer system <NUM> to perform the method <NUM> or a portion thereof.

The method <NUM> includes obtaining network data identifying at least one new event for at least one source-destination pair (step <NUM>).

In one or more embodiments, the data store <NUM> may receive new flow events in the form of network data and this may be done periodically such as for example every minute, every five (<NUM>) minutes, every thirty (<NUM>) minutes, every hour, every twenty four (<NUM>) hours, etc. Specifically, the server computer system <NUM> may send a request for new flow events to one or more source or destination computer systems connected thereto and the new flow events may be received in the form of network data. The server computer system <NUM> may send the received network data to the data store <NUM> for storage.

The server computer system <NUM> may analyze the at least one new event to determine whether or not the at least one new event is associated with a source-destination pair that is known to be trusted. For example, the server computer system <NUM> may consult a whitelist stored in the data store <NUM> that includes a list of IP addresses that are known to be trusted to determine that the at least one new event is associated with a source-destination pair that is known to be trusted. Responsive to determining that the at least one new event is associated with a source-destination pair that is known to be trusted, the server computer system <NUM> may drop the at least one new event and take no further action.

Responsive to determining that the at least one new event is not associated with a source-destination pair that is known to be trusted, the server computer system <NUM> sends a request to the data store <NUM> for all network data available for the at least one source-destination pair. Put another way, the server computer system <NUM> does not only request network data associated with the at least one new event, but rather the server computer system <NUM> requests all available network data for the at least one source-destination pair associated with the at least one new event.

The method <NUM> includes engaging the feature extraction engine to generate a set of dyads for the at least one source-destination pair associated with the at least one new event (step <NUM>).

The network data obtained by the server computer system <NUM> is sent to the feature extraction engine to generate a set of dyads for the at least one source-destination pair associated with the at least one new event. As mentioned, the set of dyads may include a number of flow events, a mean of bytes down, a standard deviation of bytes down, a mean of bytes up, a standard deviation of bytes up, a communication interval mean, a communication interval standard deviation, a communication interval skew, a communication interval kurtosis, a number of local end points that made a connection to the destination and a number of remote end points that the local endpoint connected to.

The method <NUM> includes sending the set of dyads to the machine learning engine for classification (step <NUM>).

The set of dyads are sent to the machine learning engine for classification.

The method <NUM> includes receiving, from the machine learning engine, data classifying the source-destination pair as one of benign or malware (step <NUM>).

As mentioned, the machine learning engine is trained to classify network data as one of benign network data or malware network data. Specifically, the machine learning engine analyzes the set of dyads to classify the network data as benign network data or malware network data.

The machine learning engine may classify the source-destination pair as one of benign or malware and this may be based on classifying the network data as benign network data or malware network data. For example, in embodiments where the network data is classified as malware network data, the at least one source-destination pair may be classified as malware.

In embodiments where the at least one source-destination pair is classified as benign, the server computer system <NUM> may determine that no further action is required.

In embodiments where the at least one source-destination pair is classified as malware, the server computer system <NUM> may perform one or more remedial actions. For example, the server computer system <NUM> may raise a flag or an alarm indicating that the source-destination pair is malware.

In another example, the server computer system <NUM> may add at least one of the source or destination of the source-destination pair to a blacklist. <FIG> is a flowchart showing operations performed for adding an internet protocol address to a blacklist according to an embodiment. The operations may be included in a method <NUM> which may be performed by the server computer system <NUM>. For example, computer-executable instructions stored in memory of the server computer system <NUM> may, when executed by the processor of the server computer system, configure the server computer system <NUM> to perform the method <NUM> or a portion thereof.

The method <NUM> includes receiving, from the machine learning engine, data classifying the source-destination pair as malware (step <NUM>).

The machine learning engine may perform operations similar to that described herein with reference to method <NUM> and may classify the source-destination pair as malware. In response, the server computer system <NUM> may receive, from the machine learning engine, data that classifies the source-destination pair as malware.

The method <NUM> includes adding the internet protocol address of at least one of the source or destination to a blacklist (step <NUM>).

The server computer system <NUM> may determine an IP address of at least one of the source or destination by analyzing the network data associated therewith. The server computer system <NUM> may send a signal to the data store <NUM> to add the IP address to a blacklist maintained thereby.

It will be appreciated that in addition or in alternative to identifying the IP address of the destination as malware, in one or more embodiments a fully qualified domain name (FQDM) may be identified as malware.

As mentioned, the server computer system <NUM> is a computing device. <FIG> shows a high-level block diagram of an example computing device <NUM>. As illustrated, the example computing device <NUM> includes a processor <NUM>, a memory <NUM>, and an I/O interface <NUM>. The foregoing modules of the example computing device <NUM> are in communication over and communicatively coupled to one another by a bus <NUM>.

The processor <NUM> includes a hardware processor and may, for example, include one or more processors using ARM, x86, MIPS, or PowerPC (TM) instruction sets. For example, the processor <NUM> may include Intel (TM) Core (TM) processors, Qualcomm (TM) Snapdragon (TM) processors, or the like.

The memory <NUM> comprises a physical memory. The memory <NUM> may include random access memory, read-only memory, persistent storage such as, for example, flash memory, a solid-state drive or the like. Read-only memory and persistent storage are a computer-readable medium and, more particularly, may each be considered a non-transitory computer-readable storage medium. A computer-readable medium may be organized using a file system such as may be administered by software governing overall operation of the example computing device <NUM>.

The I/O interface <NUM> is an input/output interface. The I/O interface <NUM> allows the example computing device <NUM> to receive input and provide output. For example, the I/O interface <NUM> may allow the example computing device <NUM> to receive input from or provide output to a user. In another example, the I/O interface <NUM> may allow the example computing device <NUM> to communicate with a computer network. The I/O interface <NUM> may serve to interconnect the example computing device <NUM> with one or more I/O devices such as, for example, a keyboard, a display screen, a pointing device like a mouse or a trackball, a fingerprint reader, a communications module, a hardware security module (HSM) (e.g., a trusted platform module (TPM)), or the like. Virtual counterparts of the I/O interface <NUM> and/or devices accessed via the I/O interface <NUM> may be provided such as, for example, by a host operating system.

Software comprising instructions is executed by the processor <NUM> from a computer-readable medium. For example, software corresponding to a host operating system may be loaded into random-access memory from persistent storage or flash memory of the memory <NUM>. Additionally or alternatively, software may be executed by the processor <NUM> directly from read-only memory of the memory <NUM>. In another example, software may be accessed via the I/O interface <NUM>.

It will be appreciated that the malware engine <NUM>, the feature extraction engine <NUM>, and the machine learning engine <NUM> may also be computing devices similar to that described herein.

It will be appreciated that it may be that some or all of the above-described operations of the various above-described example methods may be performed in orders other than those illustrated and/or may be performed concurrently without varying the overall operation of those methods.

Claim 1:
A method comprising:
obtaining (<NUM>) a training set of network data that includes benign network data and malware network data;
engaging (<NUM>) a feature extraction engine (<NUM>) to generate a set of dyads for each source-destination pair in the training set of network data;
training (<NUM>), using the set of dyads, a machine learning engine (<NUM>) to differentiate between the benign network data and the malware network data;
obtaining (<NUM>) network data identifying at least one new event for at least one source-destination pair;
responsive to determining that the at least one new event is not associated with a source-destination pair that is known to be trusted, sending a request to a data store (<NUM>) for obtaining all network data available for the at least one source-destination pair so as to send the network data obtained to the feature extraction engine;
engaging (<NUM>) the feature extraction engine comprising sending the network data obtained to the feature extraction engine to generate a set of dyads for the at least one source-destination pair associated with the at least one new event; and
sending (<NUM>) the set of dyads for the at least one source-destination pair associated with the at least one new event to the machine learning engine (<NUM>) for classification.