System Protection Agent Against

Unauthorized Activities via USB Devices

Jos

e Oliveira

1,2

, Miguel Frade

3,2

and Pedro Pinto

1,4

Instituto Polit

ecnico de Viana do Castelo, Viana do Castelo, Portugal

Computer Science and Communication Research Centre (CIIC), Polytechnic Institute of Leiria, Portugal

DEI ESTG, Portugal

INESC TEC, Porto, Portugal

Keywords:

USB, BadUSB, Microsoft Windows.

Abstract:

Security attacks using USB interfaces and devices are becoming more advanced, which boost efforts to develop

counter measures in order to protect systems and data. One of the most recent attacks using USB devices is

the BadUSB attack, performed by spooﬁng the device’s ﬁrmware and allowing the attackers to execute a set of

malicious actions, e.g. an USB storage device could be mounted as USB keyboard in order to inject malicious

scripts into the system. This paper proposes a protection agent against BadUSB attack developed for Windows

operative systems. It allows a user to check the class of an USB device ready to be mounted, though enabling

the detection of a potential attack if the expected functionality of the device does not match with its class type.

The results show that the proposed protection agent is capable of detecting potential intrusions by blocking

the installation of the device, scanning the device for something that identiﬁes it, searching for a description

locally and ﬁnally warning the user about the device meaning that all devices must be approved by the user

when plugged in if the system protection agent is running.

1 INTRODUCTION

Nowadays there are many kinds of malicious hard-

ware, such as back-doored network devices, back-

doored ﬁrmware of devices (printers, hard drives,

etc), keyloggers and many others. For the purpose of

this work we focused only on Universal Serial Bus

(USB) devices. USB devices are of special inter-

est due to its high availability and also often require

less user interaction to install, or no interaction at all.

These characteristics enable USB devices to offer a

large attack surface on computer systems (Jodeit and

Johns, 2010).

In (Crenshaw, 2011) four categories are used to

classify malicious USB devices, namely:

1. USB Mass Storage devices containing malware

(malicious software);

2. U3 smart drives with malicious auto-run pay-

loads;

3. Hardware key loggers

4. Programmable Human Interface Device (HID)

USB Keyboard Dongle devices.

However, new types of devices have appeared

since 2011 and thus, we propose the following up-

dated set of categories:

1. USB Mass Storage devices containing malware;

2. U3 smart drives with malicious payloads;

3. USB devices in the Middle (USBiM);

4. USB with Programmable HID;

5. Denial of Service USB device;

The updated set of categories are based on those

proposed in (Crenshaw, 2011) where the ﬁrst two cat-

egories are the same, the third and fourth categories

are renamed (to make them more general) and a ﬁfth

category is included.

Devices that fall into the ﬁrst category are the stan-

dard way to present external storage to an host Oper-

ating System (OS). USB storage devices can be used

as a way to inject malicious code to a computer (Ter-

diman, 2012; Walters, 2012) and, in case these de-

vices are shared between multiple computers, the ma-

licious code could be widely disseminated. In context

of Microsoft Windows OS, and as stated in (Sood and

Enbody, 2014), one of the most commonly exploited

Oliveira, J., Frade, M. and Pinto, P.

System Protection Agent Against Unauthorized Activities via USB Devices.

DOI: 10.5220/0006708502370243

In Proceedings of the 3rd International Conference on Internet of Things, Big Data and Security (IoTBDS 2018), pages 237-243

ISBN: 978-989-758-296-7

237

vulnerability in this type of devices is the Windows

OS autorun, which allows to execute automatically

any code or software in a Windows OS.

The second category, ”U3 smart drives with mali-

cious payloads”, groups the devices that have a spe-

cial partition that is seen as a CD-ROM device when

the device is enumerated by the host. Like the de-

vices in the ﬁrst category, these USB devices are also

used as a means to deliver malware. The device is

not malicious by itself, but it can contain ﬁles that

are malicious in nature. However, in a mass storage

USB device the infection might be accidental, but on

a U3 smart drive the infection is generally intentional

(Crenshaw, 2011).

The third category was renamed to ”USB devices

in the Middle (USBiM)” to be able to group all de-

vices that are inserted between a non malicious USB

device and the host computer. The most common de-

vices that ﬁt this category are keyloggers; some of

these are sold as forensic tools (TechGuru, 2017),

however, other devices ﬁt this category with malicious

purposes, such as printer loggers, or hardware USB

sniffers

The fourth category, ”USB with Programmable

HID”, represents a relatively new kind of threat where

malicious code is embedded in device’s ﬁrmware to

request USB interfaces that usually are not mass stor-

age. This feature provides unacknowledged and mali-

cious functionality that lies outside the apparent pur-

pose of the device (Tian et al., 2015). The advan-

tage of these type of devices is that with a USB HID

it does not matter if autorun is disabled or not. By

default, most OS seem to automatically install and

conﬁgure USB HIDs as soon as they are inserted,

regardless of the privilege level of the current user.

Author in (Crenshaw, 2011) released a blog entry de-

scribing a programmable USB device that was capa-

ble of emulating a keyboard and ”typing” out com-

mands speciﬁed in a script stored on the device. This

technique allowed commands to be executed automat-

ically by emulating a known keyboard type and ven-

dor. Authors in (Cannon, 2010; Veres-Szentkiralyi,

2012; Benchoff, 2013) developed this concept to be

able to allow perform data exﬁltration through the

USB-HID protocol. In 2016 (Kamkar, 2016) created

another type of programmable HID called PoisonTap.

This device uses a Raspeberry Pi Zero to emulate a

fast gigabit network card that is able to exﬁltrate data,

even from locked computers.

Finally, the ﬁfth category, ”Denial of Service USB

devices”, is proposed to group multiple devices that

have the malicious purpose to disrupt a service. One

Project to build a hardware USB sniffer

https://github.com/dominicgs/USBProxy

example is the USB killer (USBKill.com, 2017) that

use the USB power lines to charge its capacitors, and

then discharge 200V DC over the data lines of the

host device, burning any circuit board that does not

provide electrical surge protection

The current paper proposes a system protection

agent for Windows OS that focus into devices of the

fourth category by identifying the device functional-

ity and also, by scanning processes running on back-

ground originated from external devices. Devices

from categories one and two can also be addressed by

aiding the user to detect false USB devices, spoofed

ﬁrmware or other threats to the system that might oc-

cur from USB devices. Our proposed solution inter-

sects the operating system requests to install a de-

vice driver and hands over to the user the option to

white list or blacklist the device based on the identi-

ﬁed functionalities by the HID.

This paper is organized as follows. Section 2

presents the actual techniques used for protection

against bad USB devices. Section 3 details the pro-

posed system protection agent for Windows Operative

System based on white listing of known good USB

devices technique. Section 4 presents the validation

procedures of the current proposal. Finally, section 5

presents the conclusions and future work.

2 BACKGROUND

Awareness of USB attacks is becoming more notice-

able, since these devices can be used effectively to

deploy malicious code in computers and networks

where they connected. USB drives are a known secu-

rity threat and they were already blamed for the instal-

lation of Conﬁcker, a worm type of malware, on the

Manchester City Council computers in the year 2009

(Andreasson, 2011) (Greene, 2010). There are many

solutions to defend computer systems from malicious

USB devices, but none of them solves the problem ef-

fectively without affecting the performance of the sys-

tem or matching the end user requirements. We can

deﬁne ﬁve general categories of defense approaches:

• malicious software detection;

• disable autorun;

• behavior detection;

• physical block of USB ports;

• device installation restrictions;

Malicious software detection and disabling au-

torun are the most common defense approaches

Video of USB Killer tests on different devices

https://youtu.be/faKX P1Be50

IoTBDS 2018 - 3rd International Conference on Internet of Things, Big Data and Security

238

against malicious USB devices. These strategies work

well for USB Mass Storage devices and U3 smart

drives containing malicious payloads. According to

(Crenshaw, 2011) these storage based classes of USB

devices consist of two attack vectors. The autorun ca-

pabilities of different types of removable media make

them different than malware that spreads over a net-

work, or via a user deliberately choosing to run a

binary, but autorun is already disabled by default in

many modern OS. However, malware detection does

not work against USB devices that fall into the last

three categories of malicious devices.

Although some security software ﬁrms such as

Symantec (Ulanoff, 2014) have recommendations

about system protection against BadUSB attack, they

do not provide an effective solution for these type of

attacks.

A defensive mechanism against BadUSB attack

would allow the user to simply disable USB inputs,

notify user about a new plugged device, see what cur-

rent processes are being originated and warn the user

about it. Code signing for ﬁrmware updates could

also provide protection but only if the signed ﬁrmware

is modiﬁed. In this case, the device can not authen-

ticate the adulterated ﬁrmware and therefore will not

operate. On businesses, the threat is greater because

a thumb drive can travel lots of computers per month

or even the same day. Administrators can block USB

ports or they can install software such as Symantec

Endpoint Protection (Symantec, 2017) which has a

device control module to prevent USB devices from

mounting on the operating system (Ulanoff, 2014).

There are other platforms that can prevent BadUSB

attacks, such as Safend Protector, Sophos Endpoint

Security and many others. As seen in (Cheng, 2014),

another solution for BadUSB attacks is to adopt the

cloud which can be used as a storage method to share

information through the internet between company

members and possible partners. In GoodUSB (Tian

et al., 2015), the piece of code was capable of block-

ing the device and keep it waiting for user authen-

tication to proceed with the natural functions of the

device. It was a step further considering that it had its

own USB Honeypot mechanism focused on BadUSB

attack proﬁling.

Current paper proposes a protection agent against

BadUSB attacks. This agent identiﬁes the class of the

USB device connected to the computer with Windows

Operating System, and allows the user to block it

based on the expected device type. During the driver

installation, Windows Operating System obtains in-

formation from the device such as hardware ID and

the compatible ID and searches a INF ﬁle with more

details about the driver. If a driver as already be as-

signed to the device than the device should start work-

ing after plugging in. If it is the ﬁrst time plugging

the device, Windows Operating System uses the hard-

ware ID of the device for other manufacturer driver

and a compatible ID to search a generic driver for the

device. Finally, the protection agent will prompt the

user with the device requested interface after windows

ﬁnding out the INF ﬁle with driver information. To

the best of our knowledge, there are no free and open

source solutions to address this issue for the Windows

Operative Systems.

3 AGENT DEVELOPMENT

The proposed system protection agent maintained in

(Oliveira et al., 2017) is based on a set of functions

performed in speciﬁc stages regarding USB ports.

Windows OS generates notiﬁcations for every action

on USB ports and thus, this notiﬁcations can be cap-

tured by overriding a method called WndProc which

receives a number as a code for the event. As a new

device arrives, the system searches for it comparing

the results of Device Manager to an old list of devices

found in order to ﬁnd out a new device added.

The protection agent also needs to separate work-

ing devices from the pending devices, usually, while

getting the class of the device, if the class is null it

will throw an exception since it has not been assigned

yet. In this case, the device is probably pending and

requires a driver. Devices who returned error are later

added to a list of pending devices. The list of pending

devices also needs a ﬁlter to determine what type of

devices are relevant and irrelevant.

Although windows device manager separate de-

vices according to their class as seen in Figure 1, the

proposed protection agent selects speciﬁc USB de-

vices by ﬁltering devices by their hardware ID (i.e.

the three ﬁrst characters of the hardware id should be

USB or HID).

Figure 1: Device manager separating devices according to

functionality.

For driver installation the system scans two sep-

arate folders where windows stores the inf ﬁles con-

System Protection Agent Against Unauthorized Activities via USB Devices

239

taining the driver information. These inf ﬁles can be

opened as a txt ﬁle and are scanned in search for spe-

ciﬁc keywords that help us determine what interface is

the device asking. By searching the driver details in-

stead of just installing it, allows the end user to know

what type of device is connected to the computer.

In Figure 2 it is presented an overall schema of

the three stages used by our agent proposal. First the

agent will block the device installation on Registry,

then it will perform device detection and last, it will

install the driver for a speciﬁc device manually. These

stages are detailed in the next sections.

Figure 2: Functional Steps Performed by Protection Agent.

3.1 Registry

The Registry is a system database where system com-

ponents and some applications retrieve stored infor-

mation about conﬁguration data (Fisher, 2017). This

information varies according to the version of Win-

dows OS. The registry stores information about user

preferences, conﬁgurations for the operating system,

software, hardware devices and many others. As Win-

dows OS modiﬁes the list of installed devices, soft-

ware or any other object on the system, new values on

registry will be added, edited or even removed. Win-

dows OS installs drivers automatically without asking

for user permission, this is a vulnerability that some

malicious devices use to get inside Windows OS and

inject malicious code.

If the host has a Pro version of Windows OS, there

is an option to prevent the installation of Plug and

Play devices in the Local Group Policy Editor. We can

mimic that procedure by adding a speciﬁc key to the

registry that denies device installation and using this

agent instead to install drivers manually with a more

user friendly interface. This originates a new prob-

lem, by blocking installation of all devices we are not

just blocking USB devices but all types of devices.

To solve this, we implemented a GateKeeper which

is a simple mechanism that works basically with the

same logic as the GateKeeping Theory. The Gate-

Keeping Theory, originally created by Kurt Zadek

Lewin (1890-1947), a Psychologist and pioneer in

Social Psychology, was ﬁrst time used to describe

a wife buying food, selecting what food should end

up on the dinner table and what should not (Roberts,

2005). Most commonly adopted by the media that de-

termines what information should be displayed to the

audience and what should not, this information can be

from different types such as policy, religion and so on.

Figure 3 presents the gatekeeping theory, where from

the list of total items some are selected and others re-

jected.

Figure 3: GateKeeping Theory, from the list of total items

to the selected ones and the rejected.

3.2 Device Detection

The applications on Windows OS can capture sys-

tem notiﬁcations if it registers itself using the method

RegisterUsbDeviceNotification, this way we are

able to know when a device is plugged in and the sys-

tem protection agent can proceed scanning the device.

Although we detect every device arrival, we do not

need to block those which do not communicate over

USB protocol; it was used the GateKeeping Theory.

We used Gatekeeping Theory explained in previ-

ous section to solve the issue of the previous registry

key that was blocking the installation of all devices

and made the system protection agent install automat-

ically devices by scanning the hardware, ﬁnding the

ID and comparing the resulting string value with USB

and HID.

3.2.1 WndProc

For every action that occurs on USB ports, win-

dows generates a notiﬁcation that can be captured

by overriding a method called WndProc which is an

application-deﬁned function that processes messages

set to a window and receives a code number for the

event. Multiple code numbers are speciﬁed such as

code number 0x0007 or DBT DEVNODES CHANGE ob-

tained when device added or removed, code number

0x0219 or WM DEVICECHANGE used to notify a change

of hardware conﬁguration of a device or the computer,

and code number 0x8000 or DBT DEVICEARRIVAL ob-

tained when a new device gets plugged in.

When a new device is plugged in, the system

searches for it comparing the results of Device Man-

ager list of devices with an old list of devices found,

should a device repeat itself, the loop will skip the

iteration until it ﬁnds a new device and if it was actu-

ally plugged in or out. In other words, this protection

IoTBDS 2018 - 3rd International Conference on Internet of Things, Big Data and Security

240

agent does not fetch a new device, it simply veriﬁes

a difference between connected devices and, after the

WndProc function is called, the new list of connected

devices.

3.2.2 Device Enumeration with

ManagementObjectSearcher

ManagementObjectSearch collects management ob-

jects based on a query and is one of the most used

to retrieve management information. It can be used,

as an example, to enumerate the disk drives, network

adapters and other types of hardware, processes and

many other management objects on Windows. Af-

ter instantiated, an instance of this class uses a WMI

query (Microsoft, 2017a).

On context, a ManagementObjectSearch in-

stance will be used to get all devices connected to

Windows by using the Get() method. When this

method is invoked, ManagementObjectSearcher

runs the query and returns the collection of manage-

ment objects which should contain a list of all devices

on the system.

An instance of ManagementObjectSearcher can

be instantiated with different constructors but, on this

case, it only required a value of type string which con-

tained the query to get all the devices.

3.2.3 Windows Management Instrumentation

(WMI)

WMI (Microsoft, 2017c) is an infrastructure that al-

lows data management as well as other operations

such as task automation for windows based opera-

tive systems. According to Microsoft, WMI can be

used in all Windows-based applications and is very

useful in administrative scripts or even enterprise ap-

plications . The system is using WMI to retrieve data

from the devices using a speciﬁc class called win32

pnpentity. This class represents all the information of

a plug and play device and inside this class is a vari-

able which should tell the interface of the device.

In the Figure 4 it is presented a system internal

ﬂow diagram. For each device that this system is able

to retrieve, a new object is created to save all the in-

formation of the device. The class used for this object

contains information about the device, such as class,

name, ID and others which, in case of the blocked

device, should appear empty and only have the hard-

wareID and the compatibleID.

3.2.4 Searching for INF

The system protection agent uses a simple function to

search the correct inf for the captured device. It scans

Figure 4: System internal ﬂow diagram.

two different folders:

1. INF

2. FileRepository

The ﬁrst folder is where the agent starts scanning ﬁrst,

opening any folders inside and searching for all the

ﬁles with extension ”.inf”. For every ﬁle with this ex-

tension, the system will read all the lines and check

for the hardware ID or the compatible ID of the de-

vice. Once the system detects a match between the

hardware ID or compatible ID of the device with a

peace of the line, meaning that the line contains a

string with one of those IDs, it adds the ﬁle full path

to a list of strings that stores every compatible INF

location.

In order to ﬁnd the true identity of the device,

this system protection agent searches on those pos-

sible INF ﬁles for speciﬁc keywords such as SvcDesc

which should help determine the identity of the de-

vice. As an example, a thumb drive should be recog-

nized as a USB storage device according to the infor-

mation obtained from this line:

USBSTOR.SvcDesc = "USB Mass Storage

Driver"

System Protection Agent Against Unauthorized Activities via USB Devices

241

3.3 Install Driver

When in the stage of installing a driver, there is a func-

tion called UpdateDriverForPlugAndPlayDevices

that given a INF ﬁle and the hardware ID of a de-

vice this native function will install a driver for certain

device that uses USB protocol to communicate (Mi-

crosoft, 2017b). In the current proposal, the function

is called once the user accepts the device plugged in

after receiving information about interface. Whether

it is a keyboard, mouse or any other type of device, the

previous result ( see Section 3.2 and Figure 4 ) should

return enough information about the device that the

user is trying to connect to the Windows Operative

system.

4 VALIDATION TESTS

The proposed protection agent was built and de-

ployed in a Windows 10 Pro Creators Update, ver-

sion 10.0.15063. After the execution of the protec-

tion agent the same was tested against many devices

such as thumb drives, keyboards, mice and pointing

devices, network adapters and other types of USB de-

vices. When plugged in, if allowed on the settings

panel, all tested USB devices triggered the graphi-

cal interface presented in Figure 5 enabling the user

to choose between the USB devices that are being

blocked in the system.

Figure 5: Device SvcDesc and INF location.

The proposed system protection agent was also

tested using an Open Source Android penetration test-

ing platform, capable of HID keyboard and BadUSB

Man-in-the-middle attacks, namely the Kali Linux

Nethunter (kali.org, 2017). As result, the agent suc-

ceeded in recognizing the pseudo device as a key-

board, blocked the device and requests from user fur-

ther instructions.

The performance of the current proposal depends

if the system protection agent ﬁnds a match between

hardware ID or compatible ID of the device on the

folder with the INF ﬁles. According to the OS ver-

sion, the amount of devices connected prior to the

ﬁrst launch of this system protection agent, it can take

some milliseconds to ﬁnd a match because the total

number of INF ﬁles will probably not be the same in

every computer. Printing the current ﬁle path to the

console while scanning the ﬁles will also result on a

delay between device connection and possible class

notiﬁcation and therefore the output on the console is

only used for testing purposes.

5 CONCLUSIONS AND FUTURE

WORK

Security attacks using USB interfaces and devices im-

pose high risks to users and companies. In particu-

lar the BadUSB attack allows attackers to inject mali-

cious scripts into a target OS.

This paper proposes a protection agent against

BadUSB attack developed for Windows operative

systems. It allows a user to check the class of an USB

device ready to be mounted, though enabling the de-

tection of a potential attack if the expected function-

ality of the device does not match with its class type.

The results show that the proposed protection

agent is capable of detecting potential intrusions by

blocking the installation of the device, scanning the

device for something that identiﬁes it, searching for a

description locally and ﬁnally warning the user about

the device meaning that all devices must be approved

by the user when plugged in if the system protection

agent is running.

In spite of the protection provided by the proposed

system agent, identifying and intercepting the instal-

lation of the devices drivers, there are limitations that

should be addressed as future work. There are some

performance issues that should also be improved and

an effective ﬁltering should also be deployed for mul-

tiple USB devices. User interaction with the proposed

system agent can also be improved in order to facil-

itate the user decision. The current implementation

still relies on the user knowledge to allow or block

the device installation and thus, there is the real risk

that malicious devices are wrongly accepted, poten-

tially harming the system.

ACKNOWLEDGEMENTS

The authors would like to thank the reviewers for their

detailed comments that helped to improve this paper.

The authors acknowledge the support by

IoTBDS 2018 - 3rd International Conference on Internet of Things, Big Data and Security

242

Fundac¸

ao para a Ci

encia e a Tecnologia (FCT)

through the Computer Science and Communication

Research Centre (CIIC), Portugal.

REFERENCES

Andreasson, K. J. (2011). Cybersecurity: public sector

threats and responses. CRC Press.

Benchoff, B. (2013). Extrating data with USB

HID. Website accessed on 2017-10-10

(https://hackaday.com/2013/01/26/extracting-data-

with-usb-hid/).

Cannon, T. (2010). Data leak prevention by-

pass. Website accessed on 2017-10-10

(http://thomascannon.net/dlp-bypass/).

Cheng, N. (2014). Protect against badusb with mobile

cloud storage. Website assessed on 2017-10-06

(https://chaione.com/blog/protect-badusb-cloud-

storage/).

Crenshaw, A. (2011). Plug and prey: Malicious usb devices.

Proceedings of ShmooCon.

Fisher, T. (2017). What is the Windows Reg-

istry? Website assessed on 2017-10-06

(https://www.lifewire.com/windows-registry-

2625992).

Greene, T. (2010). Conﬁcker worm takes Manchester police

ofﬂine for three days. Website assessed on 2017-10-06

(http://www.computerworlduk.com/security/conﬁcker-

worm-takes-manchester-police-ofﬂine-for-three-

days-18640/).

Jodeit, M. and Johns, M. (2010). Usb device drivers: A

stepping stone into your kernel. In Computer Net-

work Defense (EC2ND), 2010 European Conference

on, pages 46–52. IEEE.

kali.org (2017). Kali linux nethunter for nexus

and oneplus. Website accessed on 2017-10-13

(https://www.kali.org/kali-linux-nethunter/).

Kamkar, S. (2016). PoisonTap – exploiting locked com-

puters over usb. Website accessed on 2017-10-10

(https://samy.pl/poisontap/).

Microsoft (2017a). ManagementObjectSearcher. Website

assessed on 2017-10-06 (https://msdn.microsoft.

com/en-us/library/system.management.management-

objectsearcher(v=vs.110).aspx).

Microsoft (2017b). UpdateDriverForPlugAndPlayDe-

vices function. Website assessed on 2017-10-08

(https://msdn.microsoft.com/en-us/library/windows/

hardware/ff553534(v=vs.85).aspx).

Microsoft (2017c). Windows Management Instru-

mentation. Website assessed on 2017-10-

06 (https://msdn.microsoft.com/en-us/library/

aa394582(v=vs.85).aspx).

Oliveira, J., Pinto, P., and Frade, M. (2017). usb-

whitelisting. DOI:10.5281/zenodo.1009691

https://doi.org/10.5281/zenodo.1009691.

Roberts, C. (2005). Gatekeeping theory: an evo-

lution. Website accessed on 2017-10-13

(http://www.reelaccurate.com/about/gatekeeping.pdf).

Sood, A. and Enbody, R. (2014). Targeted cyber attacks:

multi-staged attacks driven by exploits and malware.

Syngress.

Symantec (2017). Endpoint Protection - Machine Learning

Security | Symantec. Website assessed on 2017-10-06

(https://www.symantec.com/products/endpoint-

protection).

TechGuru (2017). Reviews of the best USB key-

loggers. Website accessed on 2017-10-10

(https://nerdtechy.com/reviews-best-usb-keyloggers).

Terdiman, D. (2012). Stuxnet delivered to Iranian nuclear

plant on thumb drive. (Worm). Website assessed

on 2017-10-06 (https://www.cnet.com/news/stuxnet-

delivered-to-iranian-nuclear-plant-on-thumb-drive/).

Tian, D. J., Bates, A., and Butler, K. (2015). De-

fending against malicious usb ﬁrmware with

goodusb. In Proceedings of the 31st Annual

Computer Security Applications Conference,

ACSAC 2015, pages 261–270, New York, NY,

USA. ACM. DOI:10.1145/2818000.2818040,

(http://doi.acm.org/10.1145/2818000.2818040).

Ulanoff, L. (2014). How you can avoid a badusb

attack. Website assessed on 2017-10-06

(http://mashable.com/2014/10/03/how-can-you-

avoid-badusb/).

USBKill.com (2017). USB kill v3. Website accessed on

2017-10-10 (https://usbkill.com/products/usb-killer-

v3).

Veres-Szentkiralyi, A. (2012). Leaking data using DIY

USB HID device. Website accessed on 2017-10-

10 (http://techblog.vsza.hu/posts/Leaking data using

DIY USB HID device.html).

Walters, P. (2012). The Risks of Using Portable Devices. In

United States Computer Emergency Readiness Team.

System Protection Agent Against Unauthorized Activities via USB Devices

243