A Hybrid Approach of Mobile Malware Detection in Android

11 downloads 539196 Views 4MB Size Report
Index Terms— Android; malware detection; pattern match; system call. .... by disassembling mobile applications and constructing a control flow graph (CFG) [10].
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT)
REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT)
REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT)
REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT)
REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT)
REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT)
REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT)
REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT)
futex -> ioctl -> recvmsg -> ioctl -> clock_gettime -> … -> … ->, as illustrated in Table 1 [20]. Second, we search system calls with different calling depth and compute its frequency. The frequency of a sequential system call is defined as the appeared times of a sequential system call divided by the total number of sequential system calls with the same calling depth in an app. For depth=1, we compute the frequency of different individual system calls. For depth=2, we compute the frequency of two neighbor system calls such as futex -> rt_sigtimedwait, rt_sigtimedwait -> futex, futex -> ioctl. For depth=3, we compute the frequency of three sequential system calls such as futex -> rt_sigtimedwait -> futex, rt_sigtimedwait -> futex -> ioctl, futex -> ioctl -> recvmsg, and so on. Similarly, we can compute the frequency of sequential system calls with depth=4, 5, 6, etc., until the depth reaches the maximum number N decided ahead of time, which indicates the maximum calling depth considered in the detection. Unlike many existing approaches [1, 7, 12, 26, 29], we concern sequential system calls in the detection since many malware behave maliciously by performing a number of sequential operations or actions. Generation of Malware and Normal Pattern Sets For easy presentation, we summarize the notations used in the approach in Table 2. Notation n N MS NS MP NP T!! H! F!! MN!!

Table 2: Notation description Description The depth of a sequential system call; The maximum depth of a sequential system call; The malware set; The benign app set; The malware pattern set; The normal pattern set; The appeared times of a sequential system call k with calling depth=  n in an app; The total number of sequential system calls with calling depth=  n in an app; The frequency of a sequential system call k with calling depth=  n in an app; The total number of apps with same sequential system call k and depth=  n in the malware set;

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT)
Mt and Qn < Nt, the app is malware. If Qm < Mt and Qn > Nt, the app is normal. If Qm > Mt and Qn > Nt, cannot judge. If Qm < Mt and Qn < Nt, cannot judge. When an unknown app is detected and the result is confirmed, we can update MP and NP by considering the new app as one of the apps in MS or NS to regenerating MP and NP based on Algorithm 1. 4. PATTERN GENERATION For testing our approach, we used a set of known malware and a set of confirmed benign apps to build MP and NP. For ensuring the integrity of patterns in MP and NP, we considered different types of apps. For this purpose, we collected about 2000 different mobile apps, falling into different categories such as learning, download, tools, games, and so on, either malware or normal. We collected the malware from http://www.malgenomeproject.org. The benign apps used in our test were provided by the Ministry of Education Key Laboratory of Intelligent Network and Network security, Xi'an JiaoTong University, China. At first, we processed 300 malware and 130 benign apps with N=13 and generated 369 malware patterns in MP and 173 normal patterns in NP. Table 3 lists some malware patterns in MP and Table 4 shows some normal patterns in NP. Herein, the malware pattern weight equals to the radio between the malware pattern’s average system call frequency and the corresponding normal pattern’s average system call frequency. And we used the same way to calculate the normal pattern weight. Table 3: Some malware patterns in MP Malware Pattern Name Average call frequency

Malware Pattern Weight MW!!

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT)
recvfrom->recv->recv->recv->recv>recv->recv->recv->recv->recv->recv open->read recv->recvfrom->recv->recvfrom recvfrom>recvfrom->recvfrom->recv->recv>recv->recv->recv->recv->recv->recv->recv>recv recv->recv->recv->recv->recv->recv->recv>recvfrom->recvfrom recvfrom>recvfrom->recvfrom>recvfrom>recvfrom>recvfrom->recvfrom>recvfrom>recvfrom>recvfrom->recv->recv->recv->recv>recv

0.007990539 0.251399602 0.005337517

4.946908225 5.72495403 1.909279856

0.004794324

2.968144935

0.005846247

5.339136702

0.001808299

1.015992569

11

Table 4: Some normal patterns in NP Normal Pattern Name Average Call Normal Pattern Frequency Weights NW!! read->recvfrom->write->recvfrom 0.002070951 5.641621969 write->write->read 0.165642306 6.985732206 open->open 0.148382114 1.573095781 recvfrom->recvfrom->recv->recvfrom>recvfrom->recv->recvfrom->recvfrom 0.008704104 1.089301206 If the weight of a certain pattern is high, it implies that the pattern is more unique, and thus more significant. We define the threshold of malicious pattern matches as Mt. Over this threshold indicates the detected app is suspected as malware. We define the threshold of normal pattern matches as Nt. Over this number implies the detected app could be normal. If we select a too small Mt, it will cause some benign apps to match to a certain number of malicious patterns, which could cause false positive. But if we select a big Mt, some malware cannot satisfy the detection criteria, which causes a false negative result. Similar situations will happen if we set improper value for Nt. Therefore, we firstly need to find the best optimized value of Mt and Nt. Parameters tm and tn Determination and Detection Accuracy For generating MP and NP, we tried to determine the values of tm and tn in order to achieve the best detection accuracy. In this test, there are 204 unknown apps, including 100 malware and 104 benign apps waiting for detection. We use the malware and normal patterns generated from 300 malware and 130 benign apps. For the unknown apps, we collected the data of runtime system calls and then extracted patterns with different calling depth. First, we determined the value of tn by adjusting the threshold value of Nt. We need to detect as more as possible benign apps and reduce the false negative rate and the false positive rate at the same time. We use Python scripts to select the best value of tn at the detection server. Through previous description, we know that the values of tm and tn are bigger than 1.0. We constantly increased tn by 0.01 to detect its impact on Nt selection. Table 5 shows some representative false positive and false negative rates at different values of tn and Nt. tn 1.00 1.50 1.89

Table 5: The selection of tn False positive rate False negative rate 12% 23.0769% 8.0% 15.3846% 8.0% 0%

Nt 2 2 1

> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT)
REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT)
REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT)
REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT)
REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT)
REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT)

Suggest Documents