WO2023157014A1

WO2023157014A1 - "system and method for malware detection by cross-dimensional behavioural analysis"

Info

Publication number: WO2023157014A1
Application number: PCT/IN2023/050086
Authority: WO
Inventors: Sareena Karapoola; Nikhilesh Kumar Singh; Chester Rebeiro; Kamakoti Veezhinathan
Original assignee: Indian Institute of Technology Madras
Current assignee: Indian Institute of Technology Madras
Priority date: 2022-02-15
Filing date: 2023-01-30
Publication date: 2023-08-24
Anticipated expiration: 2024-08-15

Abstract

The present invention discloses a system (300) for malware detection. The system (300) offers a cross-dimensional analysis of network data, Operating System (OS) data and Hardware Performance Control (HPC) data, when a program required to be tested for malware is run. A plurality of data models is a binary classifier specialized for user- requirements and distinct malware classes. Independent inferences obtained from data models obtained from analysis of each of the data are aggregated by the two or more model aggregators (506a, 506b, 506c). The two or more model aggregators (506a, 506b, 506c) leverage prior knowledge and predictor statistics, to vote if the test program is malware or benign. Aggregated inferences obtained from the two or more model aggregators (506a, 506b, 506c) of each of the data are aggregated by a component aggregator (508) to yield a final classification of most confident inference indicative of the malware class of the program.

Description

“SYSTEM AND METHOD FOR MALWARE DETECTION BY CROSS- DIMENSIONAL BEHAVIOURAL ANALYSIS”

FIELD OF INVENTION

The present invention generally relates to malware detection. More specifically, the present invention relates to malware detection using machine learning, based on data from different components of the system.

BACKGROUND

Malware are programs with malicious intents. With differing attack objectives, they pose varying levels of risk to system users. The ramifications of these attacks range from user- annoying popups to ex-filtration of sensitive data, financial loss, extortion, and even sabotaging critical infrastructures. Accordingly, malware programs can be grouped into classes based on their objectives and functionalities- Potentially unwanted applications (PUA) pops up unwelcomed advertisements; Bankers stealthily steals financial credentials; Backdoors opens hidden access path for a remote adversary; Spyware stealthily exfiltrate sensitive data of its victim; Downloaders installs a malicious payload; and Ransomware encrypts the data of the victim for extortion. Ransomware that can sabotage an entire system is a high-risk malware, whereas adware and potentially unwanted applications (PUA) that are mere user-annoying in nature are low-risk malware. Table 1 provided below mentions a few notable malware classes with their objectives and corresponding risk levels.

Fig. 1 illustrates distinguishability of malware programs on the system component from benign applications, in accordance with prior art. As illustrated in Fig. 1, with differing objectives, malware classes differ in behavioural trails observed at different components of the computing stack, namely, Network, Operating system (OS), and Hardware. Backdoors are likely to leave strong indicators of their consistent communication to a remote adversary at the network as compared to OS and hardware. In contrast, spyware are likely to leave indicators on the OS when it scans a large number of files. On the other hand, ransomware are prone to trigger distinct hardware events due to the encryption it performs. Consequently, some malware classes are more easily detected at run-time in one component than the other. Hence, a holistic analysis across the three components is essential to get a comprehensive picture of malware behaviour.

A significant limitation of the state-of-the-art malware detection techniques is the one-size- fits-all approach by employing a single component to analyze malware behaviour. Network based classifiers use features from malware communications (e.g., periodicity of its communications to its command-and-control server) for detection, whereas OS -based classifiers employ features from OS logs (e.g., system call traces). On the other hand, hardware-based classifiers use micro-architectural events to detect malware. However, since observable malware behaviour varies inherently across components, as illustrated in Fig. 1, such one-dimensional solutions are bound to miss relevant indicators of the behaviour exhibited in the other components.

Traditionally, malware detection mechanisms use trails of malware activity, observable at one of the system components including - (1) Network (e.g. malware communications to its command-and-control server), (2) Operating system (e.g. system calls) and, (3) Hardware (e.g. micro-architectural events). The detection models analyze the data component using one or more of the following techniques: fixed signatures, statistics; and/or, machine- learning.

The malware detectors rely on a generic set of features to detect all malware, independent of the class, and provide a generic user response. However, with varying objectives and functionalities, malware classes differ in the features that best identify them. The models are fine-tuned for an optimal trade-off between two orthogonal user requirements - (1) a high true-positive rate (with some tolerance to mis-predictions) to detect as many malware as possible; or (2) a low false positive rate (with no tolerance to mis-predictions), to prevent any impact on benign applications. These requirements are in-turn dependent on the risk- level of the malware, where users would prioritise a high true-positive rate (TPR) for high risk malware, while preferring a low false positive rate for adware/PUA that are very similar to benign applications in behaviour i.e. network, OS and hardware. For example, at the OS, a high number of encryptions is an indicator of ransomware, whereas a high rate of file- system and registry reads are indicators of spyware. Furthermore, the user’s requirements vary for different malware classes. Above mentioned Table 1 also mentions preferred user requirement based on the risk-level of the malware classes. For high-risk malware like Ransomware, users are more likely to tolerate false positives compared to low-risk malware like PUAs. Thus, a model for high-risk malware would ideally need lower classification thresholds compared to that of low-risk malware.

Conventional solutions are sub-optimal also because they consider behavioural data components in isolation to build classifiers. Consequently, they lack the understanding of the effectiveness of a given component in identifying a malware objective, the possibility of components complementing each other in improving detection efficiency, and the possibility of components complementing each other in improving detection resilience to noise.

Therefore, an efficient method of detection of malwares of different classes is required.

OBJECTS OF THE INVENTION

An object of the present invention is to provide a multi-dimensional approach for malware detection.

Another object of the present invention is to provide predictors specialized for different classes of malwares.

Another object of the present innovation is to provide efficient aggregators to resolve conflicts between the specialized predictors.

Still another object of the present invention is to derive inferences from network, hardware, and OS components for malware detection.

Yet another object of the present invention is to leverage prior knowledge, predictor statistics, and system load conditions for malware detection.

SUMMARY OF THE INVENTION

The summary is provided to introduce aspects related to a system and method of malware detection, and the aspects are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter. In one aspect, a method for malware detection may comprise Operating System (OS) data, Hardware Performance Counter (HPC) data, and network data related to a program to be tested for maliciousness to be captured on a client device. The network data related to the client device may also be captured by a gateway connecting the client device with a network. Features may be extracted from the HPC data, the network data, and the OS data. Two or more of the network data, the HPC data and the OS data may be executed on a plurality of data models. The plurality of data models may be binary classifiers specialized for different malware classes and user-requirements. The plurality of data models may provide plurality of independent inferences of maliciousness of the program based on processing of the components. A first predefined number of data models of the plurality of data models may be pre-trained on the network data to predict maliciousness of the program. A second predefined number of data models of the plurality of data models may be pre-trained on the OS data to predict maliciousness of the program. A third predefined number of data models of the plurality of data models may be pre-trained on the HPC data to predict maliciousness of the program. The independent inferences obtained from the plurality of data models may be aggregated using a two or more model aggregators. The two or more model aggregators may separately aggregate plurality of independent inferences. For example, a model aggregator may aggregate the independent inferences obtained from the plurality of data models executed on the network data. Similarly, another model aggregator may aggregate the independent inferences obtained from the plurality of data models executed on the OS data. Further, yet another model aggregator may aggregate the independent inferences obtained from the plurality of data models executed on the HPC data. The two or more model aggregators may provide an aggregated inference of maliciousness of the program based on confidence score of each of the plurality of data models for assessment of confidence of independent inference. The confidence score may be based on one or more of predictor statistics and prior knowledge.

Three aggregated inferences may be obtained from the model aggregators implemented on three data i.e. the network data, the OS data, and the HPC data. The three outputs are likely to differ on class of the program.

Successively, a component aggregator may be used to aggregate the three aggregated inferences obtained from the model aggregators, and yield a most confident inference as a final classification. Similar to the model aggregators, the component aggregator may exploit components statistics (output confidence score obtained from the model aggregators) and prior knowledge of the same. It also considers the system load conditions to determine the most resilient system component for malware detection. The final classification may indicate if the tested program is a malware or benign. In case of a malware, the final classification also indicates the malware class of the program.

In another aspect, the present invention discloses a system for malware detection. The system may comprise a processor coupled with a memory. The memory may store a program readable by the processor for execution of method of malware detection. The system may be a middlebox server or a client device. The client device may collect the network data, the OS data, and the HPC data associated with a program. The network data related to the client device may also be captured through a gateway connecting the client device with Internet. A plurality of data models specialized for different malware classes and user-requirements may be run on the processor. The plurality of data models may provide plurality of independent inferences of maliciousness of the program based on processing of the components. The independent inferences obtained from the plurality of data models may be aggregated using a two or more model aggregators. The two or more model aggregators may separately aggregate plurality of independent inferences. A component aggregator may be used to aggregate the three aggregated inferences obtained from the model aggregators, and yield a most confident inference as a final classification indicating maliciousness and the malware class of the program. Other aspects and advantages of the invention will become apparent from the following description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings constitute a part of the description and are used to provide further understanding of the present invention. Such accompanying drawings illustrate the embodiments of the present invention which are used to describe the principles of the present invention. The embodiments 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. It should be noted that references to “an” or “one” embodiment in this invention are not necessarily to the same embodiment, and they mean at least one. In the drawings:

Fig. 1 illustrates distinguishability of malware programs on the system component from benign applications, in accordance with prior art;

Fig. 2 illustrates different malware and benign behavior for different malware classes across different components, in accordance with an embodiment of the present invention;

Fig. 3 illustrates a network diagram of a system for malware detection, in accordance with an embodiment of the present invention;

Fig. 4 illustrates a data processing and flow diagram showing details of the method performed for identification of a program as a malware, in accordance with an embodiment of the present invention;

Fig. 5 illustrates a block diagram of process flow for detection of malware in a program, in accordance with an embodiment of the present invention;

Fig. 6a illustrates probability estimates observed for different malware classes, in accordance with an embodiment of the present invention;

Fig. 6b illustrates percentage of malware rows per malware class observed during train- validate phase in the three data components, in accordance with an embodiment of the present invention;

Fig. 7 illustrates distribution of probability-estimates of the predictors on data of specialization and any other data related to the three components for malware detection, in accordance with an embodiment of the present invention;

Fig. 8 illustrates evaluation of Fl -Score observed after model aggregation at each of the three components, in accordance with another embodiment of the present invention;

Fig. 9 illustrates evaluation of Fl -Scores obtained through alternative approaches to compute C_Set in component aggregator function for different malware classes, in accordance with another embodiment of the present invention; Fig. 10 illustrates a block diagram of an auto -configuration engine, in accordance with another embodiment of the present invention;

Fig. 11 illustrates Fl -Score observed across individual components in comparison with binary classifier and multi classifier, in accordance with another embodiment of the present invention;

Fig. 12 illustrates a plot of Fl -Score of predictors in network and OS under varying system load conditions, in accordance with another embodiment of the present invention; and

Fig. 13 illustrates a plot of Fl-Score of the cryptominer specialized predictors in the three components and proposed system on cryptominer data collected under varying system load conditions, in accordance with another embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The detailed description set forth below in connection with the appended drawings is intended as a description of various embodiments of the present invention and is not intended to represent the only embodiments in which the present invention may be practiced. Each embodiment described in this invention is provided merely as an example or illustration of the present invention, and should not necessarily be construed as preferred or advantageous over other embodiments. The detailed description includes specific details for the purpose of providing a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced without these specific details.

Malware classes differ in their actions. In turn, the actions determine the quantum of malware activity on the data components: network, OS and hardware. Fig. 2 illustrates different malware and benign behavior for different malware classes across different components, in accordance with an embodiment of the present invention. In Fig. 2, darker color denotes extent of difference of activities from benign applications. As represented in Fig. 2, the network shows a high distinction in activities for backdoor, deceptor and banker, whereas OS shows distinguishable activity for ransomware and spyware. Similarly, hardware shows distinct activity in the case of ransomware. Hence, some classes are better aligned to be detected in a specific component than others. For example, a backdoor creates a reverse shell, escalates privileges, and provides code injection capabilities to a remote adversary. However, the constant factor in its attempt to execute any command from the adversary is its sustained communication with the remote server. It is observed that the average duration of network flows for a backdoor is notably different from other classes. On the other hand, spyware aims to gather information about the victim. Hence, it scans the file system, leaving' distinct trails at the OS, while its network activities are not significantly distinguishable from benign applications. Similarly, ransomware scans the files at the victim to encrypt and make them inaccessible. During the process, a high rate of reading and writing files is observable at the OS. However, the high encryption rate leaves a significant fingerprint of micro-architectural events visible at the hardware. Hence, it is crucial to explore multiple components to get a complete picture of malware activity, and build appropriate defenses.

Malware detection benefits in resilience by employing all the components. The data collected at network and hardware can be affected by other processes in the system. With an increase in system load (i.e., number of processes), the network communications of other processes get induced into the network data. Similarly, other processes sharing micro- architectural resources in the system can affect the hardware performance counters. In contrast, the OS data is collected only for the specific PID and hence is agnostic to the system load. Thus, it is crucial to employ multiple components for resilient malware detection.

Malware detection benefits from class-specific features. Within each component, malware classes differ on the feature that best expresses their maliciousness. As an example, in hardware, the performance counter event DSB2MIT_SW_CNT, which counts the number of switches from the Decode Stream Buffer (DSB) to the Micro-instruction Translation Engine (MITE), is one of the most important feature in classifying ransomware from benign applications. However, for spy ware, the corresponding feature is the event M_LD_Ret_LlHit, which counts retired loads that encounter a hit in the LI cache, in a specific cache coherency state. Thus, it is beneficial to have predictors specialized for class- specific features rather than a generic approach. Malware detection benefits if fine-tuned to appropriate user requirements. System users respond differently to different malware classes. For instance, users would want to kill ransomware as soon as possible to restrict further damage. Hence, models of high-risk malware (e.g., ransomware, spyware, backdoor) target to detect every malware sample with a high true-positive rate, while tolerating some false positives. In contrast, users are comparatively lenient to low-risk malware (e.g., PUA and deceptor) that are mere user annoying in nature. Users would prefer to kill such malware only if the prediction is precise to reduce any impact on benign applications. Thus, false positives are not a concern for such malware. The predictor classification threshold controls the trade-off between True Positive Rate (TPR) and false-positive rate (FPR). High-risk malware would require lower thresholds to promote high TPR, whereas low-risk malware would require stricter thresholds to reduce FPR. Hence, it is beneficial to have predictors specialized for class- specific user requirements.

In essence, the optimal tuple (component, detection-model, user-requirement) for each malware class is different, making it essential to have a holistic view of the data components and specialized models to improve detection efficiency. However, in the real-world scenario, the type of the test program is unknown, and hence, the specialized models perform poorly as evident in our results. An alternative approach to support specialization is to deploy a multi-class classifier, which uses a group of binary classifiers followed by a naive voting mechanism, which again affects the Fl -Score. Hence, an insightful way to aggregate the independent inferences/predictions is essential to make the most of the specialization.

Fig. 3 illustrates a network diagram of a system 300 for malware detection, in accordance with an embodiment of the present invention. The system 300 may include a middlebox server 302 server connected with client devices 304-1 to 304-n. The client devices 304-1 to 304-n may be any of a smartphone, laptop, desktop, server, or any other electronic device capable of executing one or more programs. Operating System (OS) related data and hardware logs generated as a result of execution of each program on the client devices 304- 1 to 304-n may be collected by data profilers running on the client devices 304-1 to 304-n. OS system call traces may be captured using Microsoft® Process Monitor tool. To collect the hardware logs, a user space Performance Measurement Unit (PMU) driver based on Application Programming Interfaces (APIs) may be used. The PMU driver may collect the hardware logs at a fixed time interval, such as after every 100ms. The OS related data and the hardware logs may be transmitted to the middlebox server 302. The client devices 304- 1 to 304-n may also be connected with Internet 306 through a gateway 308. The gateway 308 may use a network protocol analyzer tool to collect network data related to the client devices 304-1 to 304-n and may forward the network data to the middlebox server 302. The middlebox server 302 may process the OS related data, the hardware logs, and the network data using machine learning techniques to determine if the programs running on the client devices 304-1 to 304-n are benign or malware.

Although in the forthcoming description, the method of detection of malware has been described to be performed on the middlebox server 302, it is fairly possible to implement the method onto the client device 304 itself. In order to efficiently implement the method on the client device 304, a light-weight form of the predictors/data models may be developed and executed on the client device 304.

A testbed built similar to Fig. 3 may be used to collect the training data required for malware detection, in accordance with an embodiment of the present invention. An elaborative explanation of the method performed by the middlebox server 302 is described henceforth. Post collection of the network behavior, the OS and hardware logs, different features (mentioned below in Table 2a, 2b, and 2c) may be extracted from corresponding behavioral logs. In one implementation, 58 features were extracted at network, 11 were extracted at OS, and 54 were extracted at micro-architectural events at the hardware for detection.

Below provided Table 2a mentions different features determined for network component.

Below provided Table 2b mentions different features determined for OS component.

Below provided Table 2c mentions different features determined for hardware component.

Table 3 provided below includes a summary of number of snapshots present for each malware class across the three components i.e. network, hardware, and OS, in dataset generated by the testbed. The snapshots indicate number of flows in network, number of system call traces in OS, and number of periodic Hardware Performance Counter (HPC) logs in the hardware component.

Different proportions of the above described dataset may be used as train, validate, and test sets for data modelling using a machine learning technique. In one implementation, the dataset was split in 70:15:15 ratio to train, validate, and test data models. The dataset may be present with an even distribution of benign and malware classes.

Fig. 4 illustrates a data processing and flow diagram showing details of the method performed for identification of a program as a malware, in accordance with an embodiment of the present invention. At instance 402, a program to be tested may be executed at a client device 304. The system may test each program only during first execution of the program. To prevent repeated testing, the system may maintain a detection history of program hashes at the middlebox server 302. At instance 404, capturing of OS and hardware data may be initiated at the client device 304. Further, at instance 404, executable file of the program may be reported to the middlebox server 302. During time period t_c (data collection time), capturing of the OS and hardware (HPC) data may be completed. At instance 406, the OS and hardware (HPC) data may be reported to the middlebox server 302, by the client device 304. At instance 408, network data may be collected by the gateway 308 and may be reported to the middlebox server 302. Thereupon, during time period tf (time for feature extraction) + t_r (time for testing the program), features may be extracted from the hardware, network, and OS components, and data models/predictors specialized for different malware classes may be executed on the features. At instance 410, decision/final classification may be obtained from the data models/predictors and may be reported to the client device 304. At step 412, the client device 304 may take necessary action based on the final classification.

Fig. 5 illustrates a block diagram of process flow for detection of malware in a program, in accordance with an embodiment of the present invention. At block 502, a program to be tested for malware analysis is executed. At block 504, during execution of the program, a data collection engine may collect network data, OS data, and HPC data. At block 506 (506a through 506c), each dataset i.e. the network data, the OS data, and the HPC data may be separately provided to different components including a group of predictors (Pi through P_n) (trained data models). Each predictor may be specialized for a different class of malware and user-requirements. In one implementation, the predictors may be binary classifiers configured to infer if the program is of the malware class of its specialization or benign.

In another instance, a backdoor- specialized predictor predicts if a program is a backdoor or benign. Further, a PU A- specialized program predicts if a program is a PUA or benign.

During implementation, the predictors may output conflicting inferences. For instance, due to similarities between PUA and benign applications, the backdoor-specialized predictor may infer a PUA program as benign, while the PUA-specialized predictor may infer the PUA program as PUA. Similarly, while a backdoor- specialized predictor predicts a backdoor program with high confidence, other predictors may predict the backdoor program as a malware of their class with varying likelihood. To overcome such challenge, all the inferences/predictions obtained from the predictors may be aggregated using a configurable model aggregator, within each component, at block 506. The model aggregator 1 may aggregate the inferences/predictions obtained from the predictors executed on the network data, at block 506a. Similarly, the model aggregator 2 may aggregate the inferences/predictions obtained from the predictors executed on the OS data, at block 506b. Further, the model aggregator 3 may aggregate the inferences/predictions obtained from the predictors executed on the HPC data, at block 506c.

In one implementation, the model aggregators may multiplex output of a best-case predictor to provide an aggregated inference. The best case predictor may correspond to a predictor specialized on the class of the given test program. The best case predictor may provide an output with highest accuracy. During multiplexing by the model aggregators, predictor statistics and prior knowledge may be leveraged to assess confidence of inferences inside the components. Probability estimate of a predictor in detecting a class, which is bound to vary across the predictors, may be used as the predictor statistics. The prior knowledge may include capabilities of components to reveal certain classes, as observed during training phase of the predictors. For instance, prior knowledge that a hardware component has strong indicators of ransomware, can help assess a confidence of a ransomware specialized predictor in the hardware component. Based on the predictor statistics and the prior knowledge, a model aggregator may compute a confidence score of each predictor and may relay a most confident inference as an output derived from a component.

In the above described manner, three aggregated inferences may be obtained from model aggregators implemented in three components i.e. the network component, the OS component, and the hardware component. The three aggregated inferences are likely to differ on class of the program.

At block 508, a component aggregator may be used to aggregate the three aggregated inferences obtained from the model aggregators, and yield a most confident inference as a final classification (alternatively referred as final prediction), at block 510. Similar to the model aggregators, the component aggregator may exploit components statistics (output confidence score obtained from the model aggregators) and prior knowledge of the same. The prior knowledge may include a broader understanding of expressiveness of different components. Further, the component aggregator may also check system load, and consider an output of a resilient component for aggregation to the output (final classification). In certain scenarios, for the model aggregators and the component aggregator, multiple predictors may end up with similar confidence scores. In such scenarios, the model aggregators and the component aggregator may leverage known risk-level of the classes as a tie-breaker. The model aggregators and the component aggregator may choose a most risky class as their aggregated inference to resolve the tie.

An elaborate description of the method performed by the middlebox server 302 for detection of malware is described henceforth. Let B = {D, M, E, P} represent a group of components and modules utilized by the middlebox server 302 for detection of malware. D = {N, O, H} denotes a set of behavioral components, namely network (N), OS (O), and hardware (H). M= {mi, m2, .. m_n} denotes a set of ‘n’ malware classes. E denotes prior knowledge of B that represents the capabilities of components and predictors. P denotes a set of predictors. Each predictor is specialized to detect one malware class in M, given by below provided equation.

In above mentioned equation, Pkj denotes a predictor specialized in component ‘k’ to classify a program as malware mj or benign. The predictor takes behavioral data dk of the program as an input. The behavioral data dk may be present in multiple rows, where each row corresponds to a snapshot of features captured during execution of the program. The snapshots may be captured at different granularities across components. At the network, data may be logged for every flow, and for the OS, data may be logged at every system call. Further, the hardware component may log the HPCs at a fixed time interval, for example at 100ms intervals.

The snapshots may be pre-processed and converted into a matrix with features present as columns and rows representing each snapshot. The rows may be labelled with class(es) of the program. The predictors may be trained to predict row-wise inferences along with a probability estimate of a row being a malware class (probmalware). Fig. 6a illustrates probability estimates observed for different malware classes, in accordance with an embodiment of the present invention. The probability estimates for a program may be a cumulative average of probability estimates of rows of the matrix. As a predictor is trained row-wise, prediction of a program at test time may include some rows inferred as malware (malicious) while other rows inferred as benign. Fig. 6b illustrates percentage of malware rows per malware class observed during train-validate phase in the three data components, in accordance with an embodiment of the present invention. As illustrated in Fig. 6b, the percentage of malicious rows per program i.e. maliciousrow -percentage varies for different classes. Accordingly, the predictors P_k,j may be fine-tuned to class- specific thresholds to conclude the class of the program at test time. Hence, for the behavioral data dk of the program in component k, P_k,j outputs a tuple of its prediction r_k,j and statistics S_k,j as mentioned using below provided equation.

In above mentioned equation, r_k,j is 1 for a malware of class mj, and 0 for a benign program. Further, S_k,j denotes a tuple of {probability-estimate, malicious-row-percentage}. The statistics S_k,j is an indicator of confidence of prediction rkj.

In one implementation, the confidence of prediction obtained from the statistics S_k,j may be validated by leveraging prior-known strengths of P_k,j, to detect malware of the class m_j in components k. Such prior knowledge (prior-known strengths of P_k,j) may be obtained from an expressiveness matrix built using insights obtained from a train-validate phase. The

expressiveness matrix E may be represented as:

In above mentioned equation, e_k,j denotes an Fl -Score of P_k,j () observed using a validate set in the train-validate phase. Hence, within a component, some predictors are experts (more confident than others) as the component is most expressive for them. For example, in the hardware component, if ransomware -predictor predicts a program as ransomware, such prediction is likely to be most accurate. Accordingly, an expert set Expert_k of components ‘k’ is a set of predictors having high expressiveness in k. Such expert set (Expert*) may be denoted as:

Below provided algorithm covers the complete method performed by the middlebox server 302 for malware detection.

As mentioned above, an input of program y may be taken for test. For each components k, a behavioural data for the program may be received. Next, all the predictors

may be invoked. Outputs obtained from the predictors may are a set of predictions (R_k, =

Independent predictions present in the set of predictions (R_k) are likely to have conflicts. Further, the statistics (S_k) need not be directly comparable to identify the most confident prediction in the set of predictions (R_k). This is because, the specialization in each predictor may induce class specific constraints in comparing confidence. Since the middlebox server 302 does not have a notion of the program class to begin with, an insightful aggregation is essential. Hence, the middlebox server 302 invokes a model aggregator function to aggregate the independent predictions in the set of predictions (R_k). The model aggregator may take each prediction in the set of predictions (R_k), the statistics (S_k), and the expert set (Expert_k) of predictors in k as the input. Internally, the model aggregator may use S_k and Expert_k to evaluate the confidence of each prediction in R_k. The model aggregator may return an aggregated inference based on a most confident prediction

of the components.

At the components level, three independent predictions and their

corresponding confidences are present. Such predictions are likely to

differ on the class.

may assist in identifying a confident prediction, and

may be validated by identifying most expressive components. An expressiveness score

of each prediction may be determined from the matrix

The expressiveness score

of each prediction may be represented using the below provided equation:

In the above mentioned equation,

denotes confidence of component k in predicting

Since noise induced by system load may affect detection of malware, the system load L may also be considered during malware detection. L denotes the number of processes running at the host machine.

The component aggregator function may be invoked to aggregate the three aggregated inferences obtained from the model aggregator. The component aggregator may receive the predictions , the confidences the expressiveness score

and the system load as

an input. The component aggregator may evaluate the confidence of each component, and may output highly confident prediction and respective confidence Below provided algorithm covers the aggregation of predictions performed by the model aggregator.

As mentioned above, predictions Expertk for a data component k may be taken as the input. The model aggregator may aggregate predictions in a two-step process. At a first step, a consensus on the maliciousness of the program may be achieved and at a second step, a consensus on the specific class of the malware may be achieved.

To develop a consensus on the maliciousness of the program, the model aggregator may assess the predictions and statistics. The model aggregator may assess the predictions and statistics to vote if the test program is malware or benign using a PredictIfMalware() function. The PredictIfMalware() function may be realised in one or more alternative approaches to infer a malware. The one or more alternative approaches may include: a) if at-least one of prediction is malware (logical-OR function), b) if most predictions are malware (majority-vote), c) if aggregated confidence of malware predictions is higher than benign predictions (most-confident), d) using a learning model that learns to multiplex the output of the predictors to the output (multiplexer), and e) using a learning model that learns to minimize the loss function of specialized predictors (booster).

In another implementation, to aggregate confidences of predictions, the model aggregator may use a Mean-probability-difference i.e. a mean difference between the probability- estimates of malware and benign class of all predictors. Alternatively, the model aggregator may use Mean-maliciousness-difference i.e. a mean difference between percentage of malicious and benign rows inferred for a program, by all predictors. As also illustrated in Fig. 6b, for instance, the mean-maliciousness-difference is sub-optimal to aggregate confidence as the percentage of malicious rows varies for each class. During a test run, only 30% of the network rows were predicted as malicious for most spyware programs, while downloader programs had at-least 50% of the rows inferred as malicious. Hence, the most- confident PredictIfMalware() function infers malware when mean-probability-difference is greater than 0, and benign otherwise. On the other hand, the learning models may use predictions and statistics from train-validate phase as training data (X = R, S) to predict the target-label denoted by Y. For a multiplexer, the target-label

for every malware class mj in data X, is the prediction of the corresponding specialized predictor P_k,j. On the other hand, for booster, the target-label are the original labels mj for programs of

class mj.

An aggregation-loss is a difference between an Fl -Score of PredictlfMalwareQ function as compared to the baseline i.e. the Fl-Score achieved by a predictor specialized for a malware class. Table 4 provided below mentions aggregation losses for alternative approaches of PredictIfMalware() function in the model aggregator and GetConfidentSet() function in component aggregator in the component aggregator.

Above provided Table 4 illustrates a negative loss. A negative loss indicates that the aggregation is able to improve detection performance beyond that of the specialized predictor. The naive voting mechanisms such as logical-OR or majority- vote may have high aggregation losses.

While PredictIfMalware() function may detect most malware, logical-OR function may lead to a high False Positive Ratio (FPR), whereas majority-vote may miss to detect malware in cases where only less than half of the predictors detect it.

As evident from details present in Fig. 6a, performance of most-confident mechanism may be sub-optimal as the range of probability estimates that differentiates malware and benign are different for each predictor. In contrast, a learning based mechanism may learn these class-specific ranges of probability-estimates, boosting the performance of both OS and hardware components by at least 1%, while reducing the aggregation loss to as low as 4.76% in the network component.

Fig. 7 illustrates distribution of probability-estimates of the predictors on data of specialization and any other data related to the three components for malware detection, in accordance with an embodiment of the present invention. As illustrated in Fig. 7, data of specialization present the distribution of mean-probability-difference observed when predictors predict program of their specialization, whereas the other data represent the corresponding distribution when predicting programs of any other class. After achieving a consensus on maliciousness of malware program as a malware or benign, probability estimates (Sk) of individual predictions may be used to identify the most confident predictor. However, the estimates may become unreliable when a predictor specialized for one class attempts to predict on data of any other class. As evident, the distributions overlap significantly in the OS and hardware component as compared to the network. The overlapping distributions makes identifying the malware objective class non-trivial, making confidence (probability-estimate) a poor metric to aggregate class in model aggregator. Alternatively, a predictor may have a confidence-window if the distributions are far apart, such as for spy ware in network component where distance between their inter-quartile range is large. Hence, a predictor is highly confident, if the statistics of its prediction falls in confidence windows. As evident, the confidence window may help aggregate predictions in network or hardware component, whereas in OS the confidence window may get unreliable. Alternatively, in one implementation, the predictions of the expert set (Expert_k) may be considered alone.

If the test program is identified as a malware, the model aggregator may evaluate confidences of all predictions r_k,j that predicted the malware i.e. when rk,j =1. For malware prediction, a configurable function GetConfidentSet() is employed for evaluating the statistics (S_k) and the expert set (Expert_k,) to return a confident set of predictor(s) denoted by C_Set, as mentioned above in the algorithm covering aggregation of predictions by the model aggregator. A confident set of predictor(s) may be predicted by the GetConfidentSet() function using one of the following metrics: a) confidence, that returns the predictor with high probability estimates, b) expressiveness, that considers expert predictors in Expertk alone to choose predictors with high probability estimates, and c) confidence-window, that returns the predictors whose statistics fall within their respective confidence window. Use of the aforementioned metrics may return a set of confident predictors.

There may be contentions in confident set of predictor(s) obtained by different metrics. To resolve the contentions in confident set of predictor(s), the model aggregator may prioritize the classes in accordance to the risk categories, and the most risky class in C_ Set may be output as the prediction of the components. Fig. 8 illustrates evaluation of Fl -Score observed after model aggregation at each of the three components, in accordance with an embodiment of the present invention. As illustrated in Fig. 8, the Fl-Score obtained for each of the three components with model aggregator for different metrics of GetConfidentSet() function for different malware classes are compared with a baseline Fl-score. The baseline for comparison is the Fl -Score achieved with that of a specialized predictor. The class of a program may be considered to be correctly detected if the risk-level of the predicted class is the same or higher than that of the program required to be tested. Referring back to Table 4, the model aggregator may achieve an error-rate of as low as 4% in the output of a components when presented with any malware class. In contrast, the predictors that effectively detects its class of specialization, fails to reliably detect other classes.

Successively, the component aggregator selects a most confident prediction from the outputs of the three independent model aggregators. The component aggregator may weigh components based on the empirical confidence of their prediction observed at test-time

or the prior-known strengths of each components

Alternatively, each of the three components may be weighed based on their resilience to noise and system load. At higher loads, the OS component is the most stable, as OS logs are collected specific to the process identifier, and hence are noise-free. In contrast, the network and hardware may get noisier with increase in the number of processes.

Below provided algorithm covers the process of aggregation of predictions performed by the component aggregator.

As mentioned above, the component aggregator may obtain predictions from each component

corresponding confidences

expressiveness-scores

of the components, and a system load (L) as input in making the prediction in The system load

denotes a number of processes running on a system. At lower system loads, a confident set of predictors (C_Set) may be computed using one or more approaches. Such approaches may include: a) most-confident approach for selection of the prediction having high confidence, b) most-expressive approach for selection of the prediction having high expressiveness score, and c) majority select approach for selecting the prediction that is common between two components.

Similar to the model aggregator, the component aggregator may resolve contentions in confident set of predictors obtained by different metrics by choosing the most risky class in C_Set as the prediction of the components. At higher system loads, the OS component is most stable, and hence the component aggregator may output the predictions of the OS component directly.

Fig. 9 illustrates evaluation of Fl -Scores obtained through alternative approaches to compute C_Set in component aggregator function for different malware classes, in accordance with an embodiment of the present invention. The baseline for comparison is the Fl-Score of the best data component for the malware class. A class prediction is considered to be correct, when the risk of the predicted class is same or higher than that of program class. As illustrated in Fig. 9, using expressiveness, the component aggregator may be able to detect all malware classes with aggregation gain of 1:42% over the predictors, and detect the objective class of the program with a loss as low as 7:86%.

With malware behaviour changing over time, the predictors and the model aggregators would need to be updated. A mechanism for incremental updating of the predictors and the model aggregators is described henceforth with reference to Fig. 10. Fig. 10 illustrates a block diagram of an auto -configuration engine 1002, in accordance with an embodiment of the present invention. The auto -configuration engine 1002 receives a train-test data from the three components, malware classes, and the user requirements as input. Based on the input, the auto-configuration engine 1002 generate updated predictors, updated model aggregators, and updated component aggregators as output.

With rampant increase in the number of malware classes, the number of specialized predictors is bound to increase three times (one for each data component), increasing the complexity of aggregator functions and overheads. Hence, having specialized models for each class may get computationally expensive and time consuming. To avoid such complexity, models sharing common features and user requirements in the 3-tuple may be clubbed to reduce the number of predictors in each component. Locality Sensitive Hashing (LSH) may assist in identifying the similarity of test programs to previously tested program hashes. Accordingly, LSH may assist in enabling only the relevant specialized predictor or data components to decrease overheads.

Below provided are details related to implementation of the system and evaluation of the method performed for malware detection.

A dataset of real-world malware behavior observed at network, OS and hardware for a common set of malware samples was generated. The dataset contained 10, 434 labelled Windows® malware samples from a notable Antivirus company and 150 popular benign applications from CNET. The ground truth consisted of diverse classes with AV-specific labels that included the target (i.e. Win32/Win64), family lineage, and specific name of malware. To generate objective-specific labels, a strategy similar to AV-Class was adopted. Descriptive meta-data reports from various online resources was extracted and collated to determine the objective of each sample. The objective-based classes in the dataset included banker, spyware, backdoor, ransomware, cryptominer, downloader, PUA, and deceptor malware.

A real-world testbed was designed to profile malware behavior at different system components. The testbed included features for enabling large scale malware analysis, high fidelity to real-world conditions using actual systems and internet connectivity while ensuring isolation and containment of malicious behaviors, stateless evaluations, and automation. The features as illustrated in Table 2a, 2b, and 2c were extracted from the behavioral logs of the OS, hardware, and network. Accordingly, each row in the data represent a snapshot of network flow, system call in OS, and periodic HPC measurement in hardware as described in above mentioned Table 4. The dataset was split in 70:15:15 ratio into train, validate and test sets with an even distribution of benign and malware classes.

The predictors and the aggregators were implemented in python™ using XGBoost library. Each predictor was trained with train-validate set of specialization set. Next, each predictor was tested with train-validate sets of all other malware classes. Predictions and statistics from the train-validate sets for the aggregators were obtained. The aggregators were implemented using LightGBM libray in python™.

Post implementation, performance the system was evaluated using the dataset provided above in Table 3. The performance and resilience of the system was compared against the best-case predictors of all malware classes, as well as against generic multi-class classifiers. The overheads incurred by the system were also evaluated.

Fig. 11 illustrates Fl-Score observed across individual components in comparison with binary classifier and multi classifier, in accordance with an embodiment of the present invention. The binary classifier infers if a program is malware or benign and the multi classifier infers a class of the program.

As illustrated in Fig. 11, the performance of classifiers used in present system was compared to the individual predictors across the three components, to detect the corresponding malware classes. It was observed that the binary classifier leveraged the holistic view of components to aggregate the best-case prediction similar to the predictor specialized for any malware classes. The aggregation boosted the average performance of the binary classifier by 1.14%, compared to that achieved with best-case predictors across the three components. The binary classifier achieved an Fl -Score of 1 for most malware classes and an average score of 0.93 for any malware class. While gaining performance in high-risk malware, the performance of low-risk malware slightly dropped due to aggregation. On the other hand, aggregating the correct class of the malware incurred an aggregation loss of 7.86%. The multi classifier considered a detection successful if it predicted for any malware class or a riskier class for the test program. Hence, though PUA was successfully detected, its measure in the multi classifier dropped as the riskier class Deceptor was chosen when resolving conflicting predictions during aggregation.

Performance of the system was also evaluated under varying noise infiltration induced by system load. A number of processes were used in the system to measure noise. Benign applications from CNET were run in multiples of 10 in the background while running the malware programs and collecting the corresponding data at network, OS, and hardware. Benign applications represented use-case scenarios. Fig. 12 illustrates a plot of Fl-Score of predictors in network and OS under varying system load conditions, in accordance with an embodiment of the present invention. As illustrated in Fig. 12, performance of the network component decreases while the OS component is agnostic to system load.

In another implementation, resilience of the system was compared using the case of cryptominer, which is best detected in hardware. Fig. 13 illustrates a plot of Fl-Score of the cryptominer specialized predictors in the three components and proposed system on cryptominer data collected under varying system load conditions, in accordance with an embodiment of the present invention. As illustrated in Fig. 13, performance of hardware component though higher than OS and network at lower system loads, decreases significantly as load increases. In contrast, the OS component is agnostic to system load and outperforms both the network and hardware components as soon as more than 10 additional user applications start executing simultaneously. Hence, the OS component is the most resilient to noise.

Hence, system proposed by present invention leverages best of the three components (OS, network, and hardware) to achieve optimal and resilient malware detection. At lower system loads, the system may prioritize network and hardware components for aggregation, whereas, at higher system loads, the reliable OS component may be used for prediction.

Table 5 provided below mentions Fl -Score observed using generic multi-classifiers on dataset utilized by present invention.

In the above mentioned Table 5, the data for respective classifiers had equal distribution of samples from all the classes. Performance of the system proposed by present invention was compared against alternate approaches used to classify multi-class data as mentioned above in Table 5. Table 5 shows that generic binary classifiers in the three components achieved an Fl-Score of 0.65 (Network), 0.54 (OS) and 0.6 (Hardware) on the dataset containing benign programs and 8 malware classes. Suboptimal performance of the binary classifier may be because the positive class comprises different malware types, resulting in unacceptably high intra-class variance, making the modeling of malware behavior difficult. Alternatively, multi-class classifiers may be widely used in scenarios containing multiple classes. The multi-class classifiers may internally use a group of binary classifiers in one- versus-rest or one-versus-one mode, followed by a voting mechanism. As depicted in Table 5, the one-versus-rest method has inherent class-imbalance issues affecting the performance. Further, the voting mechanism is naive in both the approaches of one-versus- rest or one-versus-one mode, affecting the prediction Fl -Score. In contrast, present invention provides specialization but may aggregate the predictions effectively to provide an optimal prediction, with Fl-Score of 100% for most malware classes.

Overheads at the end-hosts were evaluated using a GeekBench tool. It was observed that end-hosts incurred an average overhead of 1.5% at the first execution of a test program. The end-hosts (client-agents) were responsible only for the collection of OS and hardware data, whereas the heavy-weight operations of feature extraction and predictors were run on the middlebox server. The middlebox server required dedicated provision of resources and the impact on users was minimal (1.5%) and was restricted to execution of new applications alone. Below mentioned are the technical advantages of present invention. Malware detection benefits in accuracy: a) from a cross-dimensional view of malware activity, b) using class-specific features, and c) with fine-tuning to appropriate user requirements. Malware detection benefits in resilience by employing all the components.

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.

Any combination of the above features and functionalities may be used in accordance with one or more embodiments. In the foregoing specification, embodiments have been described with reference to numerous specific details that may vary from implementation to implementation. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention, and what is intended by the applicants to be the scope of the invention, is the literal and equivalent scope of the set as claimed in claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction.

Claims

CLAIMS:

1. A method of malware detection, the method comprising: receiving two or more of network data, Operating System (OS) data, and Hardware Performance Counter (HPC) data associated with a program running on a client device (304); executing a plurality of data models on each of two or more of the network data, the OS data, and the HPC data to obtain a plurality of independent inferences of maliciousness of the program, wherein a first predefined number of data models of the plurality of data models are pre-trained on the network data to predict maliciousness of the program, a second predefined number of data models of the plurality of data models are pre-trained on the OS data to predict maliciousness of the program, and a third predefined number of data models of the plurality of data models are pre-trained on the HPC data to predict maliciousness of the program; separately aggregating, by two or more model aggregators (506a, 506b, 506c), the plurality of independent inferences corresponding to each of two or more of the network data, the OS data, and the HPC data, to obtain two or more aggregated inferences of maliciousness of the program; and aggregating, by a component aggregator (508), the two or more aggregated inferences to obtain a final classification indicating maliciousness of the program.

2. The method as claimed in claim 1, wherein each data model of the plurality of data models is a binary classifier specialized for user-requirements and a distinct class of malware.

3. The method as claimed in claim 1, wherein the plurality of data models infer whether the program is malware or benign.

4. The method as claimed in claim 1, wherein the final classification indicates the malware class of the program.

5. The method as claimed in claim 1, wherein one or more of predictor statistics and prior knowledge are utilised to compute a confidence score of each of the plurality of data models for assessment of confidence of the plurality of independent inferences.

6. The method as claimed in claim 5, wherein the aggregated inference is obtained based on the confidence score.

7. The method as claimed in claim 1, wherein the final classification is determined based on a most confident output obtained from the two or more model aggregators (506a, 506b, 506c).

8. The method as claimed in claim 1, wherein the final classification is determined based on one or more of predictor statistics, prior knowledge, system load, and system noise.

9. A system (300) for malware detection, the system (300) comprising: a processor; and a memory storing programmed instructions executable by the processor, wherein the processor executes the programmed instructions to: collect two or more of network data, Operating System (OS) data, and Hardware Performance Counter (HPC) data associated with a program running on a client device (304), execute a plurality of data models on each of two or more of the network data, the OS data, and the HPC data to obtain a plurality of independent inferences of maliciousness of the program, wherein a first predefined number of data models of the plurality of data models are pre-trained on the network data to predict maliciousness of the program, a second predefined number of data models of the plurality of data models are pre-trained on the OS data to predict maliciousness of the program, and a third predefined number of data models of the plurality of data models are pre-trained on the HPC data to predict maliciousness of the program, separately aggregate the plurality of independent inferences corresponding to each of two or more of the network data, the OS data, and the HPC data, to obtain two or more aggregated inferences of maliciousness of the program, and aggregate the two or more aggregated inferences to obtain a final classification indicating maliciousness of the program.

10. The system (300) as claimed in claim 9, wherein the system (300) is implemented on one of a middlebox server (302) or the client device (304).

11. The system (300) as claimed in claim 9, wherein the network data related to the client device (304-n) is collected through a gateway (308) connecting the client device (304-n) with Internet (306).

12. The system (300) as claimed in claim 9, wherein each data model of the plurality of data models is a binary classifier specialized for user-requirements and a distinct class of malware.

13. The system (300) as claimed in claim 9, wherein the plurality of data models infer whether the program is malware or benign.

14. The system (300) as claimed in claim 9, wherein the final classification indicates the malware class of the program.

15. The system (300) as claimed in claim 9, wherein one or more of predictor statistics and prior knowledge are utilised to compute a confidence score of each of the plurality of data models for assessment of confidence of the plurality of independent inferences.

16. The system (300) as claimed in claim 15, wherein the aggregated inference is obtained based on the confidence score.

17. The system (300) as claimed in claim 9, wherein the final classification is determined based on a most confident output obtained from the two or more model aggregators (506a, 506b, 506c).

18. The system (300) as claimed in claim 9, wherein the final classification is determined based on one or more of predictor statistics, prior knowledge, system load, and system noise.