On the Feasibility of Online Malware Detection with Performance Counters
Department of Computer Science, Columbia University, NY, NY 10027
The proliferation of computers in any domain is followed by the proliferation of malware in that domain. Systems, in- cluding the latest mobile platforms, are laden with viruses, rootkits, spyware, adware and other classes of malware. De- spite the existence of anti-virus software, malware threats persist and are growing as there exist a myriad of ways to subvert anti-virus (AV) software. In fact, attackers today exploit bugs in the AV software to break into systems.
In this paper, we examine the feasibility of building a mal- ware detector in hardware using existing performance coun- ters. We find that data from performance counters can be used to identify malware and that our detection techniques are robust to minor variations in malware programs. As a result, after examining a small set of variations within a fam- ily of malware on Android ARM and Intel Linux platforms, we can detect many variations within that family. Further, our proposed hardware modifications allow the malware de- tector to run securely beneath the system software, thus setting the stage for AV implementations that are simpler and less buggy than software AV. Combined, the robustness and security of hardware AV techniques have the potential to advance state-of-the-art online malware detection.
Copyright By PowCoder代写 加微信 powcoder
Categories and Subject Descriptors
C.0 [Computer Systems Organization]: General—Hard- ware/software interfaces; K.6.5 [Management of Com- puting and Information Systems]: Security and Pro- tection—Invasive software
General Terms
Security in Hardware, Malware and its Mitigation
Malware detection, machine learning, performance counters
1This work was supported by grants FA 99500910389 (AFOSR), FA 865011C7190 (DARPA), FA 87501020253 (DARPA), CCF/TC 1054844 (NSF), . Sloan fellowship, and gifts from Microsoft Research, WindRiver Corp, Xilinx and Synopsys Inc. Any opinions, findings, conclusions and recommendations do not reflect the views of the US Government or commercial entities.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
ISCA ’13 Tel-Aviv, Israel
Copyright 2013 ACM 978-1-4503-2079-5/13/06 …$15.00.
1. INTRODUCTION
Malware – short for malicious software – is everywhere. In various forms for a variety of incentives, malware exists on desktop PCs, server systems and even mobile devices like smart phones and tablets. Some malware litter devices with unwanted advertisements, creating ad revenue for the mal- ware creator. Others can dial and text so-called “premium” services resulting in extra phone bill charges. Some other malware is even more insidious, hiding itself (via rootkits or background processes) and collecting private data like GPS location or confidential documents.
This scourge of malware persists despite the existence of many forms of protection software, antivirus (AV) software being the best example. Although AV software decreases the threat of malware, it has some failings. First, because the AV system is itself software, it is vulnerable to attack. Bugs or oversights in the AV software or underlying system software (e.g., the operating system or hypervisor) can be exploited to disable AV protection. Second, production AV software typically use static characteristics of malware such as suspicious strings of instructions in the binary to detect threats. Unfortunately, it is quite easy for malware writers to produce many different code variants that are functionally equivalent, both manually and automatically, thus defeating static analysis easily. For instance, one malware family in our data set, AnserverBot, had 187 code variations. Alterna- tives to static AV scanning require extremely sophisticated dynamic analysis, often at the cost of significant overhead.
Given the shortcomings of static analysis via software im- plementations, we propose hardware modifications to sup- port secure efficient dynamic analysis of programs to detect malware. This approach potentially solves both problems. First, by executing AV protection in secure hardware (with minimum reliance on system software), we significantly re- duce the possibility of malware subverting the protection mechanisms. Second, we posit that dynamic analysis makes detection of new, undiscovered malware variants easier. The intuition is as follows: we assume that all malware within a certain family of malware, regardless of the code variant, at- tempts to do similar things. For instance, they may all pop up ads, or they may all take GPS readings. As a result, we would expect them to work through a similar set of program phases, which tend to exhibit similar detectable properties in the form of performance data (e.g., IPC, cache behavior).
In this paper, we pose and answer the following central feasibility question: Can dynamic performance data be used to characterize and detect malware? We collect longitudi- nal, fine-grained microarchitectural traces of recent mobile
DroidKung Bot
Signatures
Internet (Filled With Malware)
Signatures, Classifiers
Coarse-Grained: Dynamic traces
Fine-Grained: (μ)-arch execution profiles
Behavioral Analysis
Suspicious Programs
Signature Generation
Coarse Grained: Call & File Analysis
Alerts (Current)
Fine Grained: (μ)-arch Profile Analysis
Alerts (Proposed)
Android malware and Linux rootkits on ARM and Intel plat- forms respectively. We then apply standard machine learn- ing classification algorithms such as KNN or Decision Trees to detect variants of known malware. Our results indicate that relatively simple classification algorithms can detect malware at nearly 90% accuracy with 3% false positives for some mobile malware.
We also describe hardware support necessary to enable online malware detection in hardware. We propose methods and techniques for (1) collection of fine-grained runtime data without slowing down applications, (2) secure execution of AV algorithms to detect at runtime the execution of malware and (3) secure updating of the AV algorithms to prevent subversion of the protection scheme.
Another important contribution of the paper is to describe the experimental framework for research in the new area of hardware malware detection. Towards this we provide a dataset used in this research. This dataset can be down- loaded from: http://castl.cs.columbia.edu/colmalset.
The rest of the paper is organized as follows. In Section 2 we provide background on malware, then describe the key intuition behind our approach (Section 3), and explain our experimental method (Section 4), followed by evaluations of Android ARM malware, x86 Linux Rootkits and side chan- nels (Sections 5, 6, 7). We describe hardware support in Section 8 and our conclusions in Section 9.
Figure 1: AV signature creation and deployment.
tion, users anonymously send cryptographic signatures of executables to the AV vendor. The AV vendor then deter- mines how often an executable occurs in a large population of its users to predict if an executable is malware: often, un- common executable signatures occurring in small numbers are tagged as malware. This system is reported to be effec- tive against polymorphic and metamorphic viruses but does not work against non-executable threats such as malicious pdfs and doc files [8]. Further it requires users to reveal programs installed on their machine to the AV vendor and trust the AV vendor not to share this secret.
2.3 How Good is Anti-Virus Software?
Just like any other large piece of software, AV systems tend to have bugs that are easily exploited, and thus AV
BACKGROUND ON MALWARE
In this section, we provide an abbreviated and fairly in- formal introduction on malware.
2.1 What is Malware and Who Creates It?
Malware is software created by an attacker to compro- mise security of a system or privacy of a victim. A list of different types of malware is listed in Table 1. Initially cre- ated to attain notoriety or for fun, malware development today is mostly motivated by financial gains [1, 2]. There are reports of active underground markets for personal in- formation, credit cards, logins into sensitive machines in the United States, etc. [3]. Also, government-funded agencies (allegedly) have created sophisticated malware that target specific computers for espionage or sabotage [4, 5, 6]. Mal- ware can be delivered in a number of ways. To list a few, an unsuspecting user can be tricked into: clicking on links in
“phishing” emails that download and install malware, open- ing email attachments with malicious pdfs or document files, browsing web pages with exploits, using infected USB sticks or downloading illegitimate applications repackaged to ap- pear as normal applications through mobile stores.
2.2 Commercial Malware Protections
The most common protection against malware is anti- virus (AV) software. Despite what the name anti-virus sug- gests, anti-virus can also detect and possibly remove cat- egories of malware besides viruses. A typical AV system works by scanning files during load time for known signa- tures, typically code strings, of malware. Figure 1 shows how anti-virus signatures are prepared: Honeypots collect mal- ware and non-malware which are then analyzed by humans to create signatures. These signatures are then delivered to the host anti-virus software periodically.
A complementary approach to signature-based detection is also used in practice [7]. In reputation based AV detec-
Table 1: Categories of Malware
Brief Description
Malware that propagates itself from one infected host to other hosts via exploits in the OS interfaces typically the system-call interface.
Malware that attaches itself to running programs and spreads itself through users’ interactions with various systems.
Polymorphic Virus
A virus that, when replicating to attach to a new target, alters its payload to evade detection, i.e. takes on a different shape but performs the same function.
Metamorphic Virus
A virus that, when replicating to attach to a new target, alters both the payload and functional- ity, including the framework for generating future changes.
Malware that masquerades as non-malware and acts maliciously once installed (opening backdoors, interfering with system behavior, etc).
Malware that forces the user to deal with unwanted advertisements.
Malware that secretly observes and reports on users computer usage and personal information ac- cessible therein.
Malware that employs a user’s computer as a mem- ber of a network of infected computers controlled by a central malicious agency.
Malware that hides its existence from other appli- cations and users. Often used to mask the activity of other malicious software.
protections are easily bypassed. In a recent paper, Jana and Shmatikov [9] found that all of the 36 commercially available AV systems they examined could be bypassed. Specifically, they detected many bugs in the code that parse program binaries which either allowed bad code to pass undetected or gain higher privilege. They argued that the problem of building robust parsers (and hence software malware detec- tors) is not easy since the number of file formats is quite large, and many of their specifications are incomplete in sev- eral ways. Their paper demonstrates the futility in trying to secure complex, million-line softwares like AV. Unlike soft- ware detectors, the hardware malware detectors we propose do not have to deal with multiple executable formats. In- stead they work on single input format – integer streams from performance counters. Further, they are not easily turned off. Thus hardware detectors are significant step to- wards more robust detectors.
2.4 Malware Arms Race
There is an arms race between malware creators and de- tectors. The earliest detectors simply scanned executables for strings of known bad instructions. To evade these detec- tors, attackers started encrypting their payloads. The detec- tors, in response, started scanning for the decryption code (which could not be encrypted) packed with the malware. The malware creators then started randomly mutating the body of the payload by using different compilation strategies (such as choosing different register assignments or padding NOPs) to create variants [10].
In response to these advances in malware creation, de- fenders were motivated to consider behavioral detection of malware instead of static signatures. Behavior-based de- tection characterizes how the malware interacts with the system: what files it uses, the IPC, system call patterns, function calls and memory footprint changes [11, 12, 13]. Using these characteristics, detectors build models of nor- mal and abnormal program behaviors, and detect abnormal execution by comparing against pre-built behavioral mod- els. Many of these schemes use machine learning techniques to learn and classify good and bad behaviors from labeled sets [14, 15, 16, 17].
2.5 Improving Malware Detection
While behavioral schemes permit richer specification of good and bad behaviors than static checkers, they tend to have high performance overheads since the more effective ones demand creation and processing of control- and data- flow graphs. Because of their overheads behavior-based de- tectors are not typically used on end hosts, but analysts in malware-detection companies may use them to understand malware-like behaviors. All of these techniques are envi- sioned to be implemented in software.
In this work, for the first time, we use hardware perfor- mance counters for behavior based detection of malware, and describe the architecture necessary to support malware detection in hardware. Our performance counter based tech- nique is a low-overhead technique that will not only allow analysts to catch bad code more quickly, it may also be feasible to deploy our system on end hosts. Unlike static signature based detection AV, we aim to detect variants of malware from known malware signatures. Unlike reputation based system our scheme does not require users to reveal programs installed on their computer.
L1 Exclusive Hits
Arithmetic μOps Executed
Xalanc astar astar omnetpp h264 libquantum sjeng hmmer mcf bzip2-i3 bzip2-i2 bzip2-i1
Figure 2: Performance counter measurements over time in the SPEC benchmark suite. We also observe readily apparent visual differences between the applications. In- tuitively, we expect it to be possible to identify programs based on these data.
Recent research has also examined using hardware per- formance counters for detecting anomalous program behav- iors [18, 19]. This is a different and (intuitively) harder prob- lem than attempted here. The anomaly detection works aim to detect small deviations in program behavior during an at- tack such as a buffer overflow or control flow deviation from otherwise mostly benign execution. In contrast, we attempt to identify execution of whole programs such as key logger when it is run, typically as the end result of exploitation such as buffer overflow vulnerability.
3. KEY INTUITION
A major thesis of this paper is that runtime behavior cap- tured using performance counters can be used to identify malware and that the minor variations in malware that are typically used to foil signature AV software do not signifi- cantly interfere with our detection method.
The intuition for this hypothesis comes from research in program phases [20, 21]. We know that programs exhibit phase behavior. They will do one activity A for a while, then switch to activity B, then to activity C. We also know that programs tend to repeat these phases – perhaps the program alternates between activities B and C. Finally, and most importantly, it has been shown that these phases correspond to patterns in architectural and microarchitectural events.
Another important property of program phases and their behaviors is that they differ radically between programs. Figure 2 plots event counts over time for several SPEC appli-
cations. In it, we see the differences between the benchmarks as well as interesting phase behavior. Given these data, it seems intuitive that these programs could be differentiated based on these time-varying signatures.
Our hypothesis that minor variations in malware do not significantly affect these data cannot be inferred from pre- vious work. Rather, it is based on two observations:
• First, regardless of how malware writers change their soft- ware, its semantics do not change significantly. For instance, if a piece of malware is designed to collect and log GPS data, then no matter how its writer re-arranges the code, it still collects and logs GPS data.
• Second, we assume that in accomplishing a particular task there exist subtasks that cannot be radically modified. For instance, a GPS logger will always have to warm up the GPS, wait for signals, decode the data, log it and at some future point exfiltrate the data out of the system. As a result of these invariant tasks, we would expect particular phases of the malware’s execution to remain relatively in- variant amongst variations.
Since it is not obvious that either of our arguments are true, we quantitatively test them in subsequent sections. In summary, we find that when we build detection methods using a small subset of variations, these detection methods often work on the other variations as well.
4. EXPERIMENTAL SETUP
Can simple performance metrics be used to identify mal- ware? To answer this question we conduct several feasibil- ity studies. In each, we collect performance counter data on malware and train a set of classifiers to detect malicious behavior. In addition to data from malware programs, we collect data from non-malware programs (Figure 3). Here we describe our program sets, provide details of our data collection infrastructure, describe our classifiers, and discuss types and granularity of malware detection.
4.1 Malware & Non-Malware Programs Used
In this study we used 503 malware and 210 non-malware programs from both Android ARM and Intel X86 platforms. The full list of programs is available in the dataset web- site1. The malware programs were obtained from three sources. First from the authors of previous work studying Android malware [22], and second from a website2 that con- tains a large number of malware. We also obtained two publicly available Linux x86 rootkits [23, 24]. Data from non-malware programs serve two purposes: during training as negative examples, and during testing to determine false positive rates, i.e., the rate of misclassifying non-malware.
For the purposes of this paper, we use a wide definition of malware. Malware is any part of any application (an Android APK file or rootkit binary) that has been labeled as malware by a security analyst. We use this definition to enable experimentation with a large amount of malware, which is necessary for supervised machine learning.
This definition of malware is, however, inaccurate. Much malware comes attached to legitimate code, so users often execute malware alongside their desired applications. As such, an accurate definition would require malware samples
1 http://castl.cs.columbia.edu/colmalset 2
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com