Int. J. Inf. Secur. (2015) 14:387–396DOI 10.1007/s10207-014-0261-x

REGULAR CONTRIBUTION

Investigating the detection capabilities of antivirusesunder concurrent attacks

Mohammed I. Al-Saleh · Fatima M. AbuHjeela ·Ziad A. Al-Sharif

Published online: 21 August 2014© Springer-Verlag Berlin Heidelberg 2014

Abstract Cyber security is a major concern of computingsystems. Different security controls are developed to miti-gate or prevent cyber attacks. Such controls include cryptog-raphy, firewalls, intrusion detection systems, access controls,and strong authentication. These controls mainly protect thesecure-systemproperties: confidentiality, integrity, and avail-ability. TheAntivirus software (AV) is considered the last lineof defense against variety of security threats. The AV main-tains a database of virus signatures against which it checksdata. Had a match occurred, the AV would have reacted tothe threat. Given the importance of theAV, different attackingtechniques have been developed to evade the AV detectionand render it useless. In this paper, we want to check howthe AV behaves under pressure. We make the AV extremelybusy in order to bypass its detection. We test several com-mercial AVs against three scenarios: when data flow from thehard drive (HD) into the main memory (reading), when dataflow from the main memory into the HD (writing), and whendata flow through the network (sending and receiving). Thispaper shows that when the AV is overloaded, somemalwarescan evade detection (in the reading scenario) and enjoy theexistence for much more time on the HD (in the writing sce-nario). Finally, we show that the AVs (or at least the oneswe tested in this paper) do not check network data as long asthey are not written to or read from the HD.

M. I. Al-Saleh (B) · F. M. AbuHjeelaComputer Science Department, Jordan University of Scienceand Technology, P.O. Box 3030, Irbid, Jordane-mail: misaleh@just.edu.jo

F. M. AbuHjeelae-mail: f.abuhjeela@gmail.com

Z. A. Al-SharifSoftware Engineering Department, Jordan University of Scienceand Technology, P.O. Box 3030, Irbid, Jordane-mail: zasharif@just.edu.jo

Keywords AV · Concurrent attack ·Malware detection

1 Introduction

Attackers try every possible way to penetrate systems. Theyare motivated by fame, money, political conflicts, or ideolo-gies. Destroying data, stealing sensitive information (such ascredit cards numbers and copy-righted materials), fabricat-ing, impersonating, and spamming are among cyber threats.Exploiting vulnerabilities in both of the computing systemsand humans (through social engineering) is at the heart ofcyber attacks. Closing such vulnerabilities prevents attacks.However, even after rigorous testing, no body can claim asystem to be free-of-vulnerabilities. Given the importanceof the computing systems, we have to tolerate the possiblesecurity risks for the advantage of using such systems andalleviate as much as possible from their impact. Protectingcomputing systems from cyber attacks is vital to keep themfully functional and protect users’ sensitive data. For a sys-tem to be secure, it must take care of all the security goals:confidentiality, integrity, and availability.

Security engineers have developed and deployed manysecurity controls to prevent, deter, or detect attacks. Con-trols might be deployed outside or inside systems perimeters.Firewalls, intrusion detection systems (IDS), strong authen-tication mechanisms, and encryptions are among of suchcontrols.

The Antivirus software (AV) is one of the most importantand widely used security controls. AVs are usually deployedon Microsoft Windows PCs and thus considered the last lineof defense against attacks. Two properties (besides protec-tion) make the AV a preferred security control over others:almost no false positives and (to some extent) unnoticeableperformance impact.

123

388 M. I. Al-Saleh et al.

The AV is classified according to scanning methods intosignature-based and behavior-based scanners. The signature-based scanner maintains a database of malware signatures.The scanner checks data against its database of signatures.If a match is found, then the data are considered malicious.Otherwise, the data are benign. The advantage of this scanneris that if malware signatures are extracted carefully, then thefalse-positive rate is close to zero. However, one drawbackof such scanners is that they cannot detect new malware orvariants of malware. The behavior-based scanner classifiesactivities to normal and abnormal. While normal activitiesare benign, abnormal activities are consideredmalicious. Thebehavior-based scanning increases the possibility of detect-ing new malware. However, it increases the false-positiverate.

The AV is classified according to the way it is triggeredinto on-access and on-demand scanners. The on-access scan-ner is triggered upon file system operations, such as read,write, open, or close. The on-access scanner prevents oper-ations from being completed if it finds a malicious match.In contrast, the on-demand scanner is triggered upon userrequest.

The AV is susceptible to several kinds of attacks. It canbe attacked directly by killing (or disabling) all or someof its processes, deleting some of its important files (suchas the databases), or modifying some of its execution files.Some of the AV components are parts of the Operating Sys-tem, and thus, they are generally immune against many ofthe above-mentioned attacks. Furthermore, attacking the AVmight require administrative privileges in the first place inorder to be accomplished.

Evading the AV detection by modifying the appearanceof the malware itself is the other common option for attack-ers. The AV is evaded using different well-known tech-niques: encryption, obfuscation, packing, polymorphism,and metamorphism.

This paper is different from the previous AV-evasion tech-niques. We examine the possibility of evading the AV detec-tion by launching excessive number of malicious activitiessimultaneously.

This paper is organized as follows. First, we explain ourthreat model in Sect. 2. This is followed by Sect. 3 thatexplains our methodology and experiments, and then, ourresults are shown in Sect. 4. Recommendations based on theResults Section are given in Sect. 5. A discussion and futurework are in Sect. 6. Then related work and the conclusionfollow.

2 Threat model

Figure 1 summarizes our threat model. Part a from the figureshows that the AVwould have detected themalicious activity

Fig. 1 Threat model

had it been only one. In part b, we want to examine the AVdetection in a special situation, where there are many mali-cious activities all running simultaneously. The question is:will the AV detect the malicious activities?

3 Methodology

We design our experiments to answer the following threequestionswhichmainly examine theAVbehavior under pres-sure:

1. If there are many concurrent processes1 that write mal-ware instances to the HD, is there a possibility that someinstances avoid the AV detection? If not, will they affectthe detection time?

2. If there are many concurrent processes that read malwareinstances from the HD, is there a possibility that someinstances avoid the AV detection?

3. Does the AV scan the network data at all if the data arenot written to or read from the HD? if yes, will manyconcurrent processes that send/receive malware instancesto/from the network be able to avoid the AV detection?

3.1 Experiments

3.1.1 Writing experiment

This experiment is designed to answer the first questionabove. Figure 2 shows the basic setup for this experiment. Nprocesses are spawned concurrently. Each process extractsa zipped, password-protected malware instance and writesit to the HD. All malware instances are written to differentdirectories to avoid the OS caching and thus harden the AV’sjob. Each process makes sure that the malware instance iscompletely written to the HD by checking its size after it iswritten and closed. All the AVs we test in this paper does

1 Throughout this paper, we mean the OS definition for the wordprocess.

123

Detection capabilities of antiviruses under concurrent attacks 389

Fig. 2 Writing experiment

not prevent malware instances from being written to the HD.However, it takes some time for the instances to be detectedand then removed by the AV. Right after malware instancesare written to the HD, each process computes the lifetime ofthe malware instance on the HD by computing the elapsedtime between the time of completely writing the malware tillthe time at which themalware instance is no longer exist (i.e.,deleted by the AV). All the N processes report their elapsedtimes for a later analysis.

3.1.2 Reading experiment

This experiment is designed to answer the second ques-tion above. Figure 3 shows the basic setup for this exper-iment. First, the AV is disabled to allow writing N mal-ware instances to the HD without detection. Then, the AV isenabled and themachine is rebooted. N processes are concur-rently spawned to read the N malware instances. Successfulreads are counted.

3.1.3 Networking experiment

This experiment is designed to answer the third questionabove. Figure 4 shows the basic setup for this experiment.The setup has a machine with no AV installed (call it A) andanother with AV (call it B). Amakes a TCP connection withB and then sends it a malware instance through that connec-

tion. B, in turn, receives the instance. We then wait for sev-eral minutes to check whether the receive operation triggersthe AV on B. Then, B sends the instance just received to Athrough the same TCP connection. We wait several minutesto check whether the send operation triggers the AV on B.

3.2 Environment, parameters, and procedures

3.2.1 Environment

All the experiments are conducted on a machine that hasMicrosoftWindows 7 Professional edition with Service Pack1. We chose Windows in our experiments because it formsthe customer-base for the AV vendors for the large numberof malwares attacking Windows machines.

The hardware specifications of the machine used in theexperiments are as the following:

– RAM: 4GB.– HD: 500GB.– CPU: Core i5 at 2.3GHz.

3.2.2 Parameters

We test three popular AV products: Kaspersky Anti-Virus6.0, Symantec Endpoint Protection 11.0, Sophos EndpointSecurity, and Control 10.0. All these AVs are pre-configured

123

390 M. I. Al-Saleh et al.

Fig. 3 Reading experiment

Fig. 4 Networking experiment

to do on-access scanning, where they do automatic scanningupon file systems operations. They can also do on-demandscanning upon user’s request.

Also, the malwares we used in our experiments areCodeRed, Zmist, Trojan.Packed.NsAnti (or Bloodhound.NsAnti as it is called by Symantec). These malwares areavailable from several Web sites. Even old, these malwaresare just used as a proof of concept. Furthermore, all the AVsunder investigation still detect and recognize them. Conse-quently, choosing newer ones has no significant effect on ourfindings.

Finally, the experiments are conducted while varying thenumber of processes in each run.

3.2.3 Procedures

1. Disable the Windows Automatic Update, WindowsDefender Automatic Scans, and Windows Firewall toavoid any interference with the AV.

2. Use Acronic True Image to create a clean baseline imageprior to testing to always conduct the experiments fromthe same clean point.

3. For each AV A in (Kaspersky, Sophos, Symantec):

– Install the AV A on the machine.– For each Malware M in (CodeRed, Zmist, Tro-jan.Packed.NsAnti):– For each N in (different numbers of concurrentprocesses: 1, 10, 100, 500, 1,000, 1,100, 1,300,1,500):• Do the following for 10 times to ensure consis-tency and repeatability:· Conduct an experiment ( Writing or Reading)with parameters A, M, and N.

· Clean the machine from the files written dur-ing the experiment.

· Restart the machine.• Compute the average over the 10 runs.

– Restore a clean image.

4 Results

This chapter shows the results for the experiments explainedin Sect. 3. Our goal is to investigate the behavior of the AVunder pressure and the possibility of evading its detection.We

123

Detection capabilities of antiviruses under concurrent attacks 391

present our results in three sections according to our experi-ments: Writing, Reading, and Networking.

4.1 Writing results

Figures 5, 6, and 7 show the average detection times forKaspersky, Sophos, and Symantec, respectively. The detec-tion time (as explained in the previous chapter) is the elapsedtime between completely writing a malware instance on theHD until it is detected and removed by the AV. The averageis taken over ten runs while varying the number of concur-rently writing processes. All the three figures show that allthe tested AVs are able to detect all the malware instances.However, the detection time is rapidly increasing in caseof Kaspersky and Sophos when increasing the number ofwriting processes. This means that writing many malwareinstances on the HD dramatically prolongs the lifetime of theinstances. In case of Symantec, the detection time increasesover increasing the number of processes, but it is very small,though (<1s in all runs). It is obvious that the highest detec-tion times are forTrojan.Packed.NsAnti and the lowest are forCodeRed, while Zmist comes in the middle. The figures con-clude that detection timesmainly depend on three factors: theAV, the number of processes writing malware instances, andthe tested malware. In this experiment, we also answer thefollowing question: what if wemanage to restart the machineright after completely writing the malware instances, willthe undetected-yet malware instances be ever detected? The

Fig. 5 Writing results for Kaspersky

Fig. 6 Writing results for Sophos

Fig. 7 Writing results for Symantec

Fig. 8 Remaining Zmist instances after restarting the machine

answer is yes in case of Kaspersky and Sophos. However, theanswer in no in case of Symantec. Figure 8 shows the remain-ingZmist (the other ones are omitted for that theyhave similarbehaviors) instances after restarting the machine. The figureshows that in case of Kaspersky and Sophos, many instanceswill stay undetected/un-removed forever, while Symantec isable to detect and clean all the instances before restarting themachine.

4.2 Reading results

Figures 9, 10, and 11 show the average number of mal-ware instances that are successfully read in case of Kasper-sky, Sophos, and Symantec, respectively. The averages arecomputed over ten separate runs while varying the numberof reading processes. In the Kaspersky and Sophos cases,increasing the number of concurrently reading processesincreases the number of successful reads and thus bypass-ing the detection of both AVs. It looks like that the AVs loosesome control when overloaded with such many read oper-ations. However, Symantec, as shown in Fig. 11, does notallow reading malware instances even under this pressure.The figures conclude that the number of successful read oper-ations mainly depend on three factors: the AV, the number ofprocesses readingmalware instances, and the testedmalware.

123

392 M. I. Al-Saleh et al.

Fig. 9 Reading results for Kaspersky

Fig. 10 Reading results for Sophos

Fig. 11 Reading results for Symantec

4.3 Networking results

In this experiment, we want to check first whether the AVscans the data coming/going through the network. If it does,then we want to overload the AV with many processessending/receiving malware instances. We start by sending amalware instance (CodeRed, Zmist, Trojan.Packed.NsAnti)from amachine that has noAV installed to amachine that hasanAV (Kaspersky, Sophos, or Symantec), which in turn com-pletely receives the malware instance. Unfortunately, afterconducting the experiment, we find that all the AVs (Kasper-sky, Sophos, and Symantec) we test do not complain aboutthe existence of the malware in the memory. Waiting for theAVs to catch the malware instances does not help. The onlyway the AV is triggered is if the malware instance is writtento the HD. Turning around the process so that the machine

that has an AV is sending the malware instance to the othermachine has the same effect; the AV is not triggered. Theconclusion of this experiment is that the AV (at least the AVproducts we tested) does not scan the network data (sent orreceived) as long as they are not written to or read from theHD.

4.4 Investigating more AVs

To show that our findings can be generalized, we extend ourinvestigation to include more well-known AVs. We conductthe Reading and the Networking experiments against theother AVs.

In case of the Reading experiment, we test the AVs againstreading 1,500 malware instances simultaneously. We repeatthe experiment three times for each AV and compute theaverage number of the successfully readable malware overthe three runs. Table 1 summarizes the AVs we test and theirversions. The table also shows the average number of mal-ware instances that evade the AV detection. The results areconsistentwith our previous findings. SomeAVs, such asAvgAV and ESET NOD32 AV 7, behave as Symantec AV in thatthey are able to detect all the instances. On the other hand,the other AVs, such as Panda AV and Avira AV, behave likeSophos and Kaspersky in that their detection can be evadedby excessive number of read operations. These results areinteresting because they show the diversity in the behaviorsof the tested AVs.

Furthermore, we conduct more Networking experimentsagainst other AVs that are declared to be more rigorousin checking browsing and Internet activities. The names ofthese products are attached with the “Internet Security” key-word. From their names, we expect them to be able to detectthe malware instances sent or received through the network.Table 2 summarizes the tested AVs along with their behaviorof detecting the malware. Surprisingly, the table shows thatnone of the tested AVs is able to detect the malware. This isalso consistent with our previous findings. However, all the

Table 1 Conducting the Reading experiment against more AVs

AV Version Succ. reads

Panda AV Pro 2014 13 136

Avg AV 2014 0

TotalDefense AV 9 1.3

ESET NOD32 AV 7 7 0

Avira AV 14 87.3

Comodo AV 7 0

Microsoft Security Essentials 4 110.6

We read 1,500 malware instances simultaneously. The experiment isrepeated three times and the average # of processes successfully readingprocesses is reported

123

Detection capabilities of antiviruses under concurrent attacks 393

Table 2 Conducting the networking experiment with more “InternetSecurity” AVs

AV Detected?

Panda Internet Security 2014 No

Avg Internet Security 2014 No

BitDefender Internet Security 2014 No

Avast Internet Security 2014 No

TotalDefense Internet Security No

A malware instance is received and then sent through the network

AVs are able to detect the instances if they are written to thehard drive. Just having the instances stayed in memory doesnot trigger any of the AVs.

4.5 Malicious activity inside excessive number of othernon-malicious ones

We design a new experiment to answer the following ques-tion: will a malicious activity be detected if it is buried insidemany other non-malicious ones?

In this experiment, we want to read many benign files andonly one malicious file concurrently to check whether thatmalicious file can evade the AV detection. The experimentalsetup in this experiment is very similar to that of the Readingexperiment (please refer to Sect. 3.1.2 for more details). We,however, want to highlight some points in this experiment:

– The benign file we use is putty.exe, a well-known SSHclient program.We use an executable file here because theAV is more aggressive to executable files than it is to othertypes of files [21]. Furthermore, the size of this executableis 444K, which is larger than all the malwares we tested(CodeRed,Zmist, Trojan.Packed.NsAnti),which sizes are4, 84, and 312K, respectively.

– Because we used 1,500 as the maximum number of readsin the Reading experiment, we want the total reads inthis experiment to be 1,500:1,499 for the non-malicious(putty.exe) and 1 for the malicious (CodeRed, Zmist, orTrojan.Packed.NsAnti).

– All the files are stored in different directories as we pre-viously did in the Reading experiment.

Table 3 shows that all the AVs are able to detect that mal-ware. This result emphasizes on the fact that evading thedetection of some AVs is caused from overloading themwithmany malicious activities. The rest of this section adds moreinsights and reasoning about our findings.

The AV usually scans files in steps. One of the very firstscanning steps is the bloom filtering step [3,21]. The bloomfilter can determinewhether an element belongs to a set or notvery quickly. Using bloom filter, no false negative is possible

Table 3 Reading 1,499 benign files along with one malware instance

AV Detected?

Kaspersky Yes

Symantec Yes

Sophos Yes

Panda AV Pro 2014 Yes

Avg AV Yes

TotalDefense AV Yes

ESET NOD32 AV 7 Yes

Avira AV Yes

Comodo AV Yes

Microsoft Security Essentials Yes

(i.e., if an element is really a member of a set then there is noway the filter would say that it is not). However, false positiveis possible (i.e., the filter might say it is a member while it isnot). In the context of the AV, the set is the database of virussignatures. In addition, the element to be checked against theset membership is the file to be scanned.

Using the bloom filter, the AV can very quickly determinewhether a file is benign or has the potential of being mali-cious. If the file has the potential of being malicious, thenmore scanning techniques, such as string matching and codeemulation, can be applied to avoid false positive. If the file,however, is determined to be benign in the first place by thebloom filter, then there is no need to do any extra scanning.In this experiment, it is not expected that the AV needs muchtime to determine that our benign file is really benign becauseof the expected utilization of the bloom filtering techniques.Furthermore, even if an AV is naive in that it does not doany filtering, once it determines that the file is benign it doesnot have to do any further post-scanning activities (such ascleaning or quarantining) as it would need to do otherwise.For example, in the Reading experiment, the AV really findsmany malware instances which the AV needs to handle bystarting post-scanning activities to deal with each malwareindependently. Such overloaded situation creates an oppor-tunity for some malware instances to go undetected. Moreinsights about the possible root causes of this problem are inthe Discussion.

5 Study recommendation

Based on the results presented in the previous section, wehave the following recommendations to the AV vendors:

1. The AV vendors should have someway to share the inter-nal functionalities of their productswith the security com-munity. Security researchers can study the AV products

123

394 M. I. Al-Saleh et al.

to enhance their security. Security through obscurity isnot the right way to secure systems [4]. Hiding the AVscanning thresholds does not help it to be more secure.Security researchers have to do reverse engineering orapply complicated hacking techniques in order to under-stand how the AV works and identify its shortcomings.

2. All read operations, no matter how many they are, mustbe checked by the AV. The AV must check all situationsunder which it cannot meet these criteria.

3. TheAVmust provide reliable techniques to queue all datathat need to be scanned. Restarting (or shutting down)machines should not let data escape scanning.

4. The AV products need to be more aggressive on the net-work data and be more careful in doing so because itcan affect the system usability. Reaching a good balancebetween security and usability is required. The AV cantake advantage of themulti-core processors and theGPUsto speed up the scanning process. However, not scanningdata going forth and back between the network and theRAM is not acceptable.

6 Discussion and future work

This paper presents a new dimension of attacks against AVs.We test the possibility of bypassing AVs working under pres-sure. This work extensively tests three well-known AVs:Kaspersky, Symantec, and Sophos. In order to generalize ourfindings, we extend our study to include more popular AVs.

In this paper, we report our findings regarding testing sev-eralAVs against concurrent attacks.Wedesign three differentexperiments:Writing, Reading, andNetworking. In theWrit-ing experiment, we want to check whether writing excessivenumber of malware instances simultaneously would let someof them go undetected. The results show that all the AVs letthe instances to be completely written to the hard drive. Inaddition, all the AVs are able to detect all the instances eventhough some of the AVs take much more time to detect theinstances than that of the others. The differences betweensuch AVs simply depend on how efficient their scanningengines are. The more efficient the scanning engine is, theless time to detect the malicious activity. Many factors con-tribute to the efficiency of an AV. This includes the scanningtechniques, such as string-matching algorithms, behavior-based detection algorithms, and heuristic-based detectionalgorithms. Finally, when restarting the machine, some not-detected-yet malware instances are able to stay in the harddrive and thus completely evade the detection. This is simplya failure of theAV tomaintain a queue of amust-have-to-scanlist of files. Having done so, the AVs would have scanned thefiles even after the restart has completely taken place.

Regarding the Reading experiment, our results show thatsome AVs can be evaded under pressure. Even though the

AVs are closed-source products, we try to hypothesize andreason about our findings. In general, the on-access scannerwould intermediate every read operation a process wouldmake. The results show that all the AVs are able to detecta single instance of a malware if it is read alone. The prob-lem is when the AV is overwhelmed with numerous numberof reads. Some AVs behave very well in detecting all theinstances no matter how many they are. On the other hand,the others are not behaving good. It is obvious from the twogroups that it all depends on the AV design and implemen-tation. The key point that needs to be thoroughly investi-gated is that how the AV behaves when it detects a mal-ware. The AV might have a design defect in that it does notexpect several malwares at the same time. This assumptionmight leave the system that is protected with an AV in inse-cure state. In addition, the AV might be spawning threadsor processes to deal with different scanning tasks. Havingonly one thread to scan all data would kill the system perfor-mance. Furthermore, more threads might be spawned to dealwith cases where a malware is detected. The AV will then beextremely busy doing special tasks, such as deleting or quar-antining files, specially when many malware instances aredetected simultaneously. So, multi-threaded protection sys-tem is inevitable. However, multi-threaded systems have tobe carefully designed for that many synchronization issues,and challenges will be involved. This includes race condi-tions, deadlocks, load balancing, and splitting data and tasks.One bug or design defect in that direction would leave thesystem insecure. Finally, something that is out of the con-trol of an AV is the Operating System (OS) policies andthresholds that cannot be changed or exceeded. For exam-ple, the AV might assign one thread for each read; how-ever, the OS might prevent the AV from exceeding somelimits on how many threads it can create, how much mem-ory it can allocate, or how many files it can open. Theseconditions might leave the AV ineffective. More investiga-tion in that direction and reverse-engineering AVs are futureworks.

In the Networking experiment, the “Usability versusSecurity” argument appears as a main factor. For the AV todetect the malware in our experiment, it needs to intermedi-ate all network operations. Not only that, but also it needs tocheck the network data after the Internet Protocol (IP) pack-ets arrive and get reassembled in the higher-level protocols,such as in the Transmission Control Protocol (TCP). Thisrequires from the AV to maintain a state for every networkconnection in the system and intermediate all subsequentsend/receive operations. Thus, the AV seems to drop suchkind of security at the aim of gaining better performanceand keeping the users happy. Studying the consequences ofscanning in-memory network data is a future direction.

Furthermore, we conducted our experiments in MS Win-dows platform because most AVs are deployed on Windows

123

Detection capabilities of antiviruses under concurrent attacks 395

machines. Finding a way to test against different platformsis a future direction.

In our experiments, we launch many processes that couldbe noticeable to vigilant users. However, bypassing the AVfor few (or even fractions) of seconds can be disastrous. As afuture work, we will find ways to put burden on the AVwhilebeing stealthy.

Finally, all of experiments were against reading, writing,sending, or receiving malware instances, where the malwareinstances are just objects. We never tested against a reallyactive (i.e., running) malware instances. This might have todo with heuristic-based AVs. We leave this dimension as afuture work.

7 Related work

TheAV is an essential security tool that protects users againstmany kinds of malware. It mainly works by scanning dataagainst its database of malware signatures. If a match isfound, the AV reacts with specific actions. These actions arebased on the default (or customized) settings. For example, aninfected file might be disinfected, quarantined, or removed.

There is no much research in the field of the AV, giventhe importance of it. One reason is that most AVs are com-mercial. Their detailed functionalities are not exposed tothe public because that is a part of their business. If secu-rity engineers and researchers have opportunity to examinethe code of the AV, then they may help improving it. Asfar as we know, ClamAV [11] is the only open-source AV.Researchers have conducted several works to either enhanceClamAV performance [13,15] or examine its security [3].Several works have been conducted to measure the AV per-formance [1,13,15,16,20,22,23].

Although signature matching is the main component ofthe AV, other techniques such as heuristics [9], code emu-lation, and algorithmic scanning are utilized by the modernAVs [21]. Furthermore, attackingAVs by different means hasbeen studied by security researchers [3,7]. Malware writersuse different techniques to hide their creatures and keep themundetected by AVs. These anti-detection techniques includepolymorphism, metamorphism, packing, obfuscation, anti-analysis, and anti-unpacking. This always increases the com-plexity of AV development and pushes for developing newdetection algorithms.

Several works have shown that bypassing the AV is possi-ble [5,6,8,10,12,14,17–19]. Our approach is different fromall other approaches in that we do not make any modifica-tions to the malware or the AV.We put the AV under pressureand monitor its behavior.

Finally, [2] shows that the AV has potential impact on thedigital evidence from digital forensics point of view.

8 Conclusion

Cyber security is a vital concern for computing systems.Attackers utilize every possible technique to penetrate sys-tems. Even though security engineers put tremendous effortsto protect systems, attackers find ways around the devisedprotections. Security controls are deployed either on net-works or on hosts. Controls deployed on hosts are consid-ered the last line of defense against attacks. Among others,the AV software is the most important and practical securitycontrol for the PC community. It has almost no false posi-tives. The major drawback of the AV is that it usually cannotdetect newmalware. The AVworks by checking data againsta database of malware signatures. If a match is found, thenthe data are considered malicious. It has been shown that theAV can be bypassed by several techniques: malware modi-fication, obfuscation, encryption, polymorphism, and meta-morphism. This paper presents a new dimension of attacksagainst the AV. We test the functionality of the AV workingunder pressure.We test several commercial AVs against threescenarios: excessive reading, excessive writing, and exces-sive sending/receiving. In case of the excessive reading, weshow that some malware instances can avoid the AV detec-tion. In case of the excessive writing, we show that somemalware instances can enjoy a long stay on the HD. Finally,in case of the networking, we show that the AV does notcheck network data (sent or received) at all unless they arewritten to or read from the HD. This paper sheds light forsecurity engineers, researchers, and AV venders to be awareof such attacks.

References

1. Al-Saleh, M., Espinoza, A., Crandall, J : Antivirus performancecharacterisation: system-wide view. Inf. Secur. IET 7(2), 126–133(2013)

2. Al-Saleh, M.I.: The impact of the antivirus on the digital evidence.Int. J. Electron. Secur. Digit. Forensic 5(3/4), 229–240 (2013)

3. Al-Saleh, M.I., Crandall, J.R.: Application-level reconnaissance:timing channel attacks against antivirus software. In: Proceedingsof the 4th USENIXConference on Large-Scale Exploits and Emer-gent Threats. LEET’11, pp. 9–9. USENIX Association, Berkeley(2011)

4. Bishop,M.: Computer Security: Art and Science. Addison-Wesley,Boston (2003)

5. Bishop, P., Bloomfield, R., Gashi, I., Stankovic, V: Diversity forsecurity: a study with off-the-shelf antivirus engines. In: SoftwareReliability Engineering (ISSRE), 2011 IEEE 22nd InternationalSymposium on, pp. 11–19. IEEE (2011)

6. Christiansen, M. : Bypassing Malware Defenses? SANS InstituteInfoSec Reading Room, pp. 3–4 (2010)

7. Christodorescu, M., Jha, S.: Testing malware detectors. SIGSOFTSoftw. Eng. Notes 29(4), 34–44 (2004)

8. Daryabar, F., Dehghantanha, A., Broujerdi, H.G.: Investigation ofmalware defence and detection techniques. Int. J. Digit. Inf. Wirel.Commun. (IJDIWC) 1(3), 645–650 (2012)

123

396 M. I. Al-Saleh et al.

9. Eisner, J.:UnderstandingHeuristics: SymantecsBloodhoundTech-nology. Symantec White Paper Series Volume XXXIV (1997)

10. Josse, S.: How to assess the effectiveness of your anti-virus?J. Comput. Virol. 2(1), 51–65 (2006)

11. Kojm, T.: Clamav (2004). http://www.clamav.net12. Lagadec, P.: Opendocument and open xml security (openoffice. org

and ms office 2007). J. Comput. Virol. 4(2), 115–125 (2008)13. Lin, P.-C., Lin, Y.-D., Lai, Y.-C.: A hybrid algorithm of backward

hashing and automaton tracking for virus scanning. IEEE Trans.Comput. 60, 594–601 (2011)

14. Meert, D., Teirlinckx, N.: Malware, from theory to practice(2012). http://ems2.be/Portals/6/Users/043/43/43/Paper_Final.pdf

15. Miretskiy, Y., Das, A., Wright, C.P., Zadok, E.: Avfs: an on-accessanti-virus file system. In: Proceedings of the 13th USENIX Secu-rity Symposium Security 2004, pp. 73–88. USENIX Association(2004)

16. Paul, N.R.: Disk-level behavioral malware detection. Doctoral dis-sertation, University of Virginia (2008)

17. Rad, B.B., Masrom, M., Ibrahim, S.: Evolution of computer virusconcealment and anti-virus techniques: a short survey (2011).arXiv:1104.1070

18. Ramilli, M., Bishop, M.: Multi-stage delivery of malware. In: 20105th International Conference onMalicious andUnwanted Software(MALWARE), pp. 91–97. IEEE (2010)

19. Ramilli, M., Bishop, M., Sun, S.: Multiprocess malware. In: 20116th International Conference onMalicious andUnwanted Software(MALWARE), pp. 8–13. IEEE (2011)

20. Silberstein, M.: Designing a cam-based coprocessor for boost-ing performance of antivirus software. Technion technique report(2004)

21. Szor, P.: The Art of Computer Virus Research and Defense.Addison-Wesley Professional, Boston (2005)

22. Uluski, D., Moffie, M., Kaeli, D.: Characterizing antivirus work-load execution. SIGARCHComput.Archit.News33, 90–98 (2005)

23. Vasiliadis, G., Ioannidis, S.: Gravity: a massively parallel antivirusengine. In: Proceedings of the 13th International Conference onRecent Advances in Intrusion Detection, RAID’10, pp. 79–96.Springer, Berlin, Heidelberg (2010)

123