On the Detection of Malware on Virtual AssistantsBased on Behavioral Anomalies

Mahshid Noorani∗†, Spiros Mancoridis†, Steven Weber∗∗Department of Electrical and Computer Engineering, Drexel University, Philadelphia, PA

†Department of Computer Science, Drexel University, Philadelphia, PA

Abstract—This work explores some of the security con-cerns pertaining to running software similar to AmazonAlexa home assistant on IoT-like platforms. We implementa behavioral-based malware detector and compare theeffectiveness of different system attributes that are usedin detecting malware, i.e., system calls, network traffic,and the integration of system call and network trafficfeatures. Given the small number of malware samples forIoT devices, we create a parameterizable malware samplethat mimics Alexa behavior to varying degrees, whileexfiltrating data from the device to a remote host. Theperformance of our anomaly detector is evaluated based onhow well it determines the presence of our parameterizedmalware on an Alexa-enabled IoT device.

I. INTRODUCTION

The Internet of Things (IoT) refers to the growingnetwork of “smart objects.” The increase in popularityof IoT devices, due to their efficiency and convenience,has given rise to new security concerns. These devicesreside on internal networks, have their own IP address,and allow communication with devices and systems thatare connected to the Internet. Their ubiquity, large num-bers, lack of cryptographic encryption, and weak defaultauthentication make them highly attractive targets.

The interconnected nature of IoT devices means thatevery insecure device that is connected online has thepotential to affect the security and resilience of the entireInternet. IoT devices are heterogeneous and specializeddevices by nature. However, the variety and novelty ofIoT devices has yet to yield a corpus of malware that issufficiently large to employ machine learning algorithms.This makes anomaly detection methods for IoT devicesecurity more attractive, especially in the short term,until there are enough behavioral signatures for malwareto train more sophisticated machine learning detectionmodels for these devices.

Amazon Alexa Echo is an example of a popularIoT device. This intelligent virtual assistant processesnatural language to assist people with tasks around theirhome. Alexa, similar to most IoT devices, is designedto accomplish simple and specialized tasks. We claim

that this narrow spectrum of responsibilities, which iscommon to IoT devices in general, yields a higher chanceof success using anomaly-based detection methods thatidentify deviations in measured statistics against a nor-mal model of operation of Alexa.

In this work, we built a one-class Support VectorMachine (SVM) [1] for behavioral-based anomaly detec-tion. The detector was separately trained on three sets ofsystem attributes. We will describe how it is possible todetect the existence of malware on the Alexa device byfirst training an anomaly detector on operating systemkernel layer system call data, then training an anomalydetector on network traffic data, and finally training ananomaly detector on a set of features integrated fromsystem call and network features as shown on the leftside of Figure 1.

Fig. 1: Concurrent Design of Anomaly Detector &Parameterized Malware Sample

These anomaly detectors are trained using only benign(normal) usage scenarios. Each detector is subsequentlysubjected to both regular usage scenarios and malwareinfections in order to demonstrate its effectiveness todistinguish normal Alexa operation from anomalous,perhaps malicious, operation in real time. While wedemonstrate the effectiveness of our technique on Ama-zon Alexa, we anticipate that small variations of ourtechnique can be used to create anomaly detectors forother IoT devices, because these devices are typicallyhighly specialized and, hence, exhibit a predictable nor-mal behavior. This is in contrast to creating an anomalydetector for a general purpose computer, which has a

more elaborate and varying behavioral profile.To overcome the limitation of only having a small

number of pre-existing malware samples for IoT devices,we decided to create a parameterizable malware samplethat mimics Alexa behavior to various degrees, whileexfiltrating data from the device to a remote host asshown in the right side of Figure 1. We tune thedesigned malware parameters to mimic Alexa behaviormore closely based on the feedback received from ourdetector on which features are a better representation ofAlexa behavior. The performance of each of our anomalydetectors is evaluated based on how well it determinesthe presence of our parameterized malware on an Alexa-enabled IoT device. In this work, we also have compileda labeled dataset of Alexa-Pi system calls and networktraffic features, which can be used in future studies ofIoT devices.

II. PREVIOUS WORK

As IoT devices become more prevalent and are sub-jected to more security attacks, researchers can gathermore malware samples and perform traditional mal-ware detection. Meanwhile, these shortcomings havemotivated the use of anomaly detection technique forexposing previously unseen threats. Behavioral-basedanomaly detection does not require a prior knowledge ofvulnerabilities for identifying previously unseen threats.In this method, a model of the system is created based onthe normal behavior of the system and the deviation fromthe model yields an indication of compromise. Unlikegeneral purpose computers, which consist of many dif-ferent applications, IoT devices are very specialized. Asa result, it is much easier to create an effective anomalydetector for malware detection on IoT devices. Othershave argued that the novelty of IoT makes anomalydetection a superior choice even in the long term [2][3] [4] [5].

In the prior art, data that was tainted by malwareexecutions was used as part of the model trainingprocess. In contrast, this paper focuses on anomaly-based malware detection because of the limitations oftraditional signature-based detectors (e.g., ineffective onzero-day attacks) and the fact that current IoT devicedo not yet have enough malware samples that can beused to build a robust model. Therefore, our focus ison developing detection techniques that do not require apriori information about specific threats, but rather aredesigned to detect unusual behavior from the IoT device.

Extensive research has been done on the effectivenessof a variety of system features for detecting system

anomalies. System calls and network traffic are twocategories of system features that are often used todetect system anomalies. The authors have done somerelated prior work where they developed techniques todetect anomalous behavior on home assistant devicessuch as Amazon Alexa Virtual Assistant IoT device [6].Intelligent virtual assistants, such as Alexa-enabled IoTdevices, typically have specialized functionality whichmakes their ordinary behavior easy to learn. The effec-tiveness of a semi-supervised anomaly detector, trainedby ordinary system call sequences generated by the IoTdevice’s kernel, has been studied to identify malwareactivities without needing to have seen malware samplesin training [6]. The results suggest that an anomalydetector based on system calls is capable of detectingthe presence of malware samples with significantly highaccuracy in a very short time, with only modest-sizedtraining data.

Network behavioral modeling is another popular ap-proach for malware detection and malware family clas-sification [7]. Network traffic data represent the amountand type of traffic on a particular network. They containinformation about sent and received communications ona device. The effectiveness of network traffic-based anal-ysis for detecting anomalous behavior on a system hasbeen tested using machine learning algorithms [8]. Thenetwork traffic data have been shown to be effective fortraining models that can identify anomalous behaviorson systems [9] [10].

Important advances have been made on malware de-tection in traditional personal computers over the lastdecade. However, adopting and adapting those tech-niques to smart devices is a challenging problem. Forexample, power consumption is one major constraint thatmakes it unaffordable to run traditional detection engineson IoT devices, while externalized (i.e., cloud-based)techniques raise many privacy concerns. A study of thecost and benefits of integrating system call and networktraffic to perform anomaly based detection detection forIoT devices is, therefore, of great interest. IoT is aresource constrained environment, therefore we want tomake sure we are doing the anomaly detection in a costefficient manner. Each of these processes will have a costin terms of energy, resources, and delay. In this research,we compare multiple detectors to learn if better resultsare obtained using only one of these detectors, or if ahybrid detector that uses both of these kinds of featuresis better.

III. ANOMALY DETECTION MODEL

To the best of our knowledge, currently, there areno malware samples, other than proof-of-concept ones,that target voice-controlled IoT devices that use AmazonAlexa. The lack of malicious training samples impedesresearchers carrying out supervised malware detectiontechniques. Under the assumption that not enough mal-ware samples are available, but will likely be availableeventually, anomaly detection techniques are of greatinterest for protecting IoT devices in the short term.Additionally, the rapid variation and development ofmalware in general, namely as polymorphic and meta-morphic malware [11], highlights a unique advantage ofanomaly detection over supervised approaches.

This work employs one-class SVM for anomaly de-tection. This section begins by describing our data ex-traction and preprocessing methods in §III-A, and thenproceeds with an overview of the anomaly detector.

A. Feature generation and preprocessing

Behavioral anomaly detection uses sequences of sys-tem calls and network traffic flows, and extracts featuresfrom them for the anomaly detector. Specifically, ourdetector relies on the traces of Linux OS kernel-levelsystem calls that are generated by the processes runningon the Amazon Alexa device and network traffic to andfrom Alexa-Pi.

These system calls describe what OS functions areused by each process executing on a computing platform.When a malware process starts executing, its systemcall traces will likely not match any of the benigntraces that are currently executing or have executed inthe past. System calls can be viewed as the languageof machines, and feature extraction methods in naturallanguage processing can be used to pre-process thesystem call traces.

Similar to prior work [6] we take a sequence ofsystems calls collected in an observation window oflength L as a data sample. Then, we employ the bag-of-n-grams model [12], [13] to produce the feature vectorx ∈ Rp, which is a vector of the number of the systemcall sequences that occurred in a small sliding windowof length L data samples.

Network traffic features are extracted from the pro-cessing of data captured in pcap files. Pcap files canbe analyzed by using tools such as wireshark, tshark,or Python’s scipy package. In this work, we use theCICFlowMeter tool to extract features from the pcapfiles. The CICFlowMeter is an open source tool thatgenerates bidirectional flows from pcap files, and extracts

features from these flows. The selected features haveshown to produce results with respect to both accuracyand performance, confirming that time-related featuresare conducive to producing good classifiers for encryptedtraffic characterization [14].

In the collected network traffic data, each sent orreceived network packet counts as one observation. Dur-ing the data collection in Malware mode, many packetsare transferred between Alexa-Pi and Amazon serversas they would normally in Benign mode. Only a fewpackets contain information that is specific to maliciousbehavior. In other words, the malware class contains acombination of malware and benign behavior, all labeledas malicious. As a result, labeling all collected trafficin Malware mode as malicious activity results in aninseparable dataset. This behavior is demonstrated inthe right side of Figure 2. We resolve this issue bygrouping the dataset into m-second intervals. Each newbatch contains traces of malicious behavior. As a result,our new malicious observations are more distinct formthe benign traces as shown in the left side of Figure 2.The binning size is a tunable parameter which affectsthe malware detection accuracy of the model.

Fig. 2: Malware and Benign Network Data w/ and w/oGrouping

We use percentile aggregation to group the networktraffic dataset. There is an undefined number of generatedpackets per m-seconds, since we do not know the exactnumber of samples per each time interval, our best betis to capture a probability distribution estimation of thedata using percentile aggregation. To create a reasonable-size feature vector we only aggregate the data by three,

which means replacing each feature column by three newcolumns representing the 25th, 50th and 75th percentileof the original feature. The new feature vector consistsof 237 features.

237 features were extracted from network traffic data.Approximately 3300 features were extracted from sys-tem call data. This brings the total size of the featureset to approximately 3500 features. We use PrincipalComponent Analysis (PCA) to reduce the dimensionalityof our feature space. The number of PCs were decidedon by calculating the cross-validated r-squared score forn linear combinations of features. The cross-validatedcoefficient of determination is the proportion of the vari-ance in the dependent variable that is predictable fromthe independent variable. We employ cross-validation onthe data and take the number of PCs that corresponds tothe maximum cross-validated r-squared score. Figure 3shows the cross-validated r-squared score for each PC.There is always a peak in the graph that represent theoptimum number of PCs. In this experiment, 20 is theselected number of PCs.

Fig. 3: Significance of Principal Components in PCA

B. One-class SVM-based anomaly detection algorithm

The one-class SVM finds a hyperplane that separatesthe training data from the origin with a margin thatis as large as possible. The one-class SVM’s objectivefunction minimizes the normalized weights vector wof the hyperplane (which is equivalent to maximizingthe margin), and the objective function is also penalizedby points that lie on the wrong side of the hyperplane(i.e., the side wherein the origin lies). The test statisticof the one-class SVM is the distance to the separatinghyperplane: y = wᵀφ(x)− ρ [15].

IV. EXPERIMENTAL SETUP

In this work, we implement a real IoT system almostidentical to having an Amazon Echo personal assistant

at home. We then design a behavioral based malwaredetector to detect malware by measuring the networktraffic statistics between Amazon servers to the Echodevice and back. In order to collect kernel level dataand network traffic statistics, we need an open platform.Amazon Echo is a closed system, which limits ouraccess level to this device. We built an Alexa-Pi IoTdevice, which has all of the capabilities of Amazon Echoand allows for data collection by elevating our systemprivileges. In our experiments, we used a Raspberry Pi2 Model B running Alexa Voice Service in place of anAmazon Echo Dot, which is one of the most popularsmart speakers.

A. Raspberry-Pi setup

The model of the device running the Alexa VoiceService is a Raspberry Pi 2 Model B. The operatingsystem installed on the device is a Raspbian-Stretch asprovided by the Raspberry Pi foundation website. Weuse this device as a surrogate for the Amazon Echo Dot(Gen 2) for two reasons.

First, the Amazon Echo Dot runs Amazon’s Fire OS.Because Fire OS is proprietary, we are unable to do manyof the things required to perform our data collectionon the device. However, the Raspberry Pi runs theRaspbian-Stretch operating system, which is open sourceand allows us to customize the device and access theOS kernel. While the two operating systems are differentfrom one another, they are both Unix-based, and as such,have a similar low-level functionality.

Second, the Raspberry Pi 2 Model B’s central pro-cessing unit is the Broadcom BCM2836 [16], whilethe Amazon Echo Dot’s central processing unit is theMediaTek MT8163V [17], both of which are quad-core processors whose underlying architecture is theARM Cortex-A53 micro-architecture, implementing theARMv8-A 64-bit instruction set [16], [18].

B. Alexa installation

The Alexa-Enabled devices available from Amazon(such as the Echo) are not suitable for collecting the datawe use as features for our detection model. As such, weinstalled the Amazon Voice Service on a Raspberry Pi2 Model B. To achieve feature parity with an officialAlexa-Enabled device, one must register as a developerwith Amazon, register the device upon which the AlexaVoice Service will be installed, and download some li-braries, programs, and security certificates from Amazon.With the addition of a USB microphone and analogspeakers connected via the Raspberry Pi’s 3.5mm audio

output port, a user can query the device in the same wayas one would with a device such as an Amazon Echoand receive the same results.

C. Exercising the Alexa capabilities

Currently, there is no interface available to the publicto facilitate the automatic interaction with the AlexaVoice Service for practicing built-in capabilities. The ma-jority of computation performed when making queries ishandled at a remote server rather than the Alexa-Enableddevice itself. Consequently, the system calls made on thedevice itself when handling different queries are verysimilar, as the device mostly establishes a connection toAmazon’s servers and offloads the query. Furthermore,in practical use, the device is not handling queries atall, but rather listening for a wake word. During thispassive listening state, the Amazon Voice Service isstill running and awaiting input. This means that evenwhen the device is not actively handling a query, it stillcontinually makes system calls as part of the service.As such, the pattern of behavior demonstrated whilethe device is idle is still useful in building a realisticmodel for anomaly detection. When gathering data forour experiments, we exercised a broad set of Alexa built-in capabilities from books, calendar, weather, music, andstandard built-in skills categories. We also gathered datawhen Alexa was idle, both in a quiet environment aswell as in an environment with ambient noise.

D. Malware Design

Alexa-Pi creates a recording of the user’s speech afterhearing the Wake-up word. These recordings are sent tothe Amazon servers for further analysis. The Amazonserver then sends an mp3 file back to Alexa-Pi as aresponse to the query, which gets saved in a temporaryfolder on the Alexa-Pi device. The recordings remainin the temp file until the next time Alexa hears theWake word. Alexa-Pi also sends routine token update(a token that indicates the Alexa-Pi is up and authorizedto communicate with Amazon servers) requests to theAmazon servers approximately every 3570 seconds. Thisreoccurring behavior allows us to schedule the malwareto synchronize the sending of the recording with theAlexa token update request time. This results in morestealth and less detectable malicious behavior in Idlemode. However, sending the zip files to a remote serveronly every 3570 seconds, while Alexa generates manyrecordings in Query mode, requires us to save the zippedrecordings in a folder and send them all in one attempt at3570-second intervals. Since the number of packets and

the packet size would not match Alexa’s behavior, thisapproach would result in an easily detectable malware inQuery mode. Hence, we used a second approach with theintent for our malware to remain more stealth in Querymode.

The first generation of malware mimics Alexa’s be-havior by exfiltrating the recordings saved by Alexa.We generated a family of malware that varies basedon the intensity of this operation. For example, wecollected network and system call data while zippingand sending Alexa recordings to a remote server everym seconds. We then varied the value of m to generate afamily of malware, which vary in intensity of operation.We then create three malware samples by setting thevalue of m to 5, 10, and 30 seconds. Since we queryAlexa continuously in the query mode, Alexa sendsmany packets to Amazon servers, which create a perfectopportunity for us to send the malicious packets indisguise. The malware detectability decreases as theintensity of operation decreases. Hence, the malwarewith the intensity of operation set to 30 seconds is themost successful in deceiving the detector.

The second generation of malware collects feedbackfrom our designed detector and learns which featuresused in our detection mechanism is most likely totrick the detector. The selected feature is set as anew parameter of our malware and adds an additionaldegree of freedom to our parameterized malware. Theselected parameter in this work is the Flow Durationfeature. To ensure the validity of the chosen parameterfor the 2nd generation of our malware, we tested themalware’s detectability by comparing the performanceof the detector in two scenarios. In scenario I, weenforced no constraints on the range of the flow durationparameter’s values. In scenario II, we set the malware’sflow duration value to a constant number that mimicsthe average of Alexa-Pi’s normal traffic’s flow duration.The comparison of the detectibility of the malware inscenarios I and II confirmed that the malware in scenarioII is more successful in deceiving the detector.

V. EXPERIMENTAL RESULTS AND COMPARISONS

We have conducted our experiment in three modes,namely Idle, Ambient, and Query. Idle mode is whensystem call and network traffic data is collected in anenvironment with no background noise and no ambientuser conversations. Ambient mode is when the data iscollected in an environment where there is an activeconversation happening in the room but the Wake-upword, “Alexa”, is not used in the conversation. Query

mode is when the user actively uses the Wake-up wordto initiate an interaction with the Alexa-Pi device. Ineach mode, we can create six scenarios by tuning theparameters of our malware. The performance of our threeanomaly detectors in different modes are compared inFigures 5, 6, 7.

The two selected scenarios in the left side of Figure4 are the scenarios in which the malware is most andleast likely to trick the detector. The AUC for eachdetector is summarized in a separate table: Tables I, II,and III. Each table reports the Area Under the ROCCurve (AUC) for the two selected malware modes ineach of the three environments (Idle, Ambient, andQuery). The comparison of AUC in each environmentsuggests that a combined network traffic and systemcall detector performs better than the network trafficor system call detectors individually. We observe thatour designed malware is more detectable based on thenetwork traffic analysis. The system call detector doesnot show a high detection accuracy for our malware onits own, however it seems to detect the anomalies basedon characteristics that are overlooked by the networktraffic detector. Hence, the combined network traffic andsystem call detector consistently reports higher detection.

Fig. 4: The Selected Malware Modes Shown in ROCCurves (right) and Tables (left)

Idle Ambient QueryNon Alexa-like Flow Duration m=5 1.00 0.99 0.98Alexa-like Flow Duration m=30 1.00 0.98 0.76

TABLE I: System Call Detector AUC Values For EachMode

Idle Ambient QueryNon Alexa-like Flow Duration m=5 1.00 0.98 0.97

Alexa-like Flow Duration m=30 0.87 0.94 0.73TABLE II: Network Traffic Detector AUC Values ForEach Mode

Idle Ambient QueryNon Alexa-like Flow Duration m=5 1.00 1.00 0.99Alexa-like Flow Duration m=30 1.00 0.99 0.92

TABLE III: Combined System Call and Network TrafficDetector AUC Values For Each Mode

Figures 5, 6, 7 show the accuracy of our model forthe scenario in which the malware is tuned to behavethe most similar to an Alexa-Pi IoT device as shownin the right side of Figure 4. The malware is detectable

with almost a 100 percent accuracy in Idle mode. Thedetection rate declines to 99 percent in Ambient mode,and goes down to a 89 percent in the Query mode.This decline in accuracy is expected as our malwareis designed to mimic Alexa-Pi in Query mode. Onepossible reason for the low detection accuracy using thesystem call detector is that our custom-made malwaredoes not perform traditional malicious activities, such asmalware replication and propagation, which would makeit sufficiently different from Alexa-Pi.

There is a discrepancy between the system calls ob-served when the Alexa-Pi device is Idle and placed ina quiet room, and those observed when the malware-free device is placed in a noisy room (i.e., Ambient)or when the malware-free device is being queried. Thesystem calls in the Ambient and Query modes are moresimilar to each other than to the system calls in theIdle and Ambient modes. This suggests that despite thepresence, or lack of presence, of the Wake word in aconversation, the Alexa-Pi device behaves in a similarmanner. This might be a result of the way the Alexa APIclient operates. In both Ambient and Query mode, theAlexa API client analyzes the conversations in the roomand sends them to the Wake Word Detection Engine. TheDetection Engine determines if the audio file requires aresponse. Based on our research, all audio files, with orwithout the wake word, are sent to Amazon servers bydefault. The Alexa app allows access to these files andgives the user permission to erase the saved recordings.

VI. CONCLUSIONS

This work focused on anomaly-based malware detec-tion because of the limitations of traditional signature-based detectors (e.g., ineffective on zero-day attacks)and the fact that current IoT devices do not yet haveenough malware samples that can be used to build anaccurate malware detection model. Therefore, our focuswas on developing detection techniques that do notrequire a prior knowledge of specific threats, but ratherare designed to detect notable deviations from normalAlexa’s behavior.

We designed a real IoT system and collected systemcall and network traffic data. We described the creationof behavioral anomaly detection systems designed todetect the execution of malware on an Amazon AlexaIoT device. Three detectors were designed based ondifferent system features, i.e., network traffic, systemcall, and an integration of system call and network trafficfeatures. We then created a parameterizable malware thatmimics Alexa’s behavior to varying degrees.

(a) System calls in Idle Mode (b) System call in Ambient Mode (c) System call in Query ModeFig. 5: System call ROC Curves in Each Mode

(a) Network Traffic in Idle Mode (b) Network Traffic in Ambient Mode (c) Network Traffic in Query ModeFig. 6: Network Traffic ROC Curves in Each Mode

(a) Combined Features in Idle Mode (b) Combined Features in Ambient Mode (c) Combined Features in Query ModeFig. 7: Combined Features ROC Curves in Each Mode

The key findings and contributions in this work areas follows: (I) We observed that a detector based oncombined system call and network traffic features pro-vides better detection compared to system call-basedor network traffic-based detectors individually. (II) Thiswork focused on the co-evolution of data exfiltrationmalware targeting IoT devices and anomaly detectorsbased on network and system call data. The focus of thiswork was not to optimize the detector or the malware, ingeneral, but, rather, to evolve the malware based on theinput from the detector, and vice versa. (III) We createda dataset consisting of network traffic and system calldata to study IoT devices. We are planning to make this

dataset available on GitHub.In this work, we studied the cost and benefits of

combining system call and network traffic features ofan anomaly-based detector for IoT devices. However,we did not determine the optimal contribution of eachspecific detector to the combined detector.

ACKNOWLEDGMENT

The work was funded in part by Spiros Mancoridis’Auerbach Berger Chair in Cybersecurity.

REFERENCES

[1] B. E. Boser, I. M. Guyon, and V. N. Vapnik, “A training algo-rithm for optimal margin classifiers,” in COLT ’92: Proceedingsof the fifth annual workshop on Computational learning theory.New York, NY, USA: ACM, 1992, pp. 144–152.

[2] J. Su, V. Danilo Vasconcellos, S. Prasad, S. Daniele, Y. Feng,and K. Sakurai, “Lightweight classification of iot malware basedon image recognition,” in 2018 IEEE 42nd Annual ComputerSoftware and Applications Conference (COMPSAC), vol. 02,July 2018, pp. 664–669.

[3] H. Sun, X. Wang, R. Buyya, and J. Su, “CloudEyes: Cloud-based malware detection with reversible sketch for resource-constrained internet of things (IoT) devices,” Software: Practiceand Experience, vol. 47, no. 3, pp. 421–441, Jun. 2016.[Online]. Available: https://doi.org/10.1002/spe.2420

[4] M. S. Alam and S. T. Vuong, “Random forest classificationfor detecting android malware,” in 2013 IEEE InternationalConference on Green Computing and Communications andIEEE Internet of Things and IEEE Cyber, Physical and SocialComputing, Aug 2013, pp. 663–669.

[5] H. S. Ham, H. H. Kim, M. S. Kim, and M. J. Choi,“Linear SVM-based android malware detection for reliable IoTservices,” Journal of Applied Mathematics, vol. 2014, pp. 1–10,2014. [Online]. Available: https://doi.org/10.1155/2014/594501

[6] N. An, A. Duff, M. Noorani, S. Weber, and S. Mancoridis,“Malware anomaly detection on virtual assistants,” in 2018 13thInternational Conference on Malicious and Unwanted Software(MALWARE), Oct 2018, pp. 124–131.

[7] S. Nari and A. A. Ghorbani, “Automated malware classificationbased on network behavior,” in 2013 International Conferenceon Computing, Networking and Communications (ICNC), Jan2013, pp. 642–647.

[8] W. Zhenqi and W. Xinyu, “Netflow based intrusion detectionsystem,” in 2008 International Conference on MultiMedia andInformation Technology, Dec 2008, pp. 825–828.

[9] D. S. Terzi, R. Terzi, and S. Sagiroglu, “Big data analyticsfor network anomaly detection from netflow data,” in 2017 In-ternational Conference on Computer Science and Engineering(UBMK), Oct 2017, pp. 592–597.

[10] R. Vaarandi, “Detecting anomalous network traffic in organi-zational private networks,” in 2013 IEEE International Multi-Disciplinary Conference on Cognitive Methods in SituationAwareness and Decision Support (CogSIMA), Feb 2013, pp.285–292.

[11] T. Moffitt, “Source code for Mirai IoT malware released,”Webroot Threat Blog, October 2016.

[12] R. Canzanese, S. Mancoridis, and M. Kam, “System call-baseddetection of malicious processes,” in IEEE QRS, Aug 2015, pp.119–124.

[13] N. An, A. Duff, G. Naik, M. Faloutsos, S. Weber, and S. Man-coridis, “Behavioral anomaly detection of malware on homerouters,” in 2017 12th MALWARE, Oct 2017, pp. 47–54.

[14] A. H. Lashkari., G. D. Gil., M. S. I. Mamun., and A. A.Ghorbani., “Characterization of tor traffic using time basedfeatures,” in Proceedings of the 3rd International Conference onInformation Systems Security and Privacy - Volume 1: ICISSP,,INSTICC. SciTePress, 2017, pp. 253–262.

[15] B. Scholkopf, J. C. Platt, J. Shawe-Taylor, A. J. Smola,and R. C. Williamson, “Estimating the support of a high-dimensional distribution,” Neural computation, vol. 13, no. 7,pp. 1443–1471, 2001.

[16] Raspberry-Pi-Foundation, “BCM2836,” Oct. 2016. [On-line]. Available: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2836/README.md

[17] WikiDevi, “Amazon Echo Dot (RS03QR).” [Online]. Available:https://wikidevi.com/wiki/Amazon Echo Dot (RS03QR)

[18] MediaTek, “Mediatek MT8163V/A for tablets.” [Online].Available: https://www.mediatek.com/products/tablets/mt8163