�antifying the Reflective DDoS A�ack Capabilityof Household IoT Devices∗

Minzhao Lyu†, Daniel Sherra�†, Arunan Sivanathan†,

Hassan Habibi Gharakheili†, Adam Radford?, Vijay Sivaraman†

†Electrical Engineering and Telecommunications, University of New South Wales, Sydney, Australia?Cisco Systems, Sydney, Australia

{m.lyu,a.sivanathan}@student.unsw.edu.au,dgsherra�@gmail.com,h.habibi@unsw.edu.au,aradford@cisco.com,vijay@unsw.edu.au

ABSTRACTDistributed Denial-of-Service (DDoS) a�acks are increasing in fre-quency and volume on the Internet, and there is evidence thatcyber-criminals are turning to Internet-of-�ings (IoT) devices suchas cameras and vending machines as easy launchpads for large-scale a�acks. �is paper quanti�es the capability of consumer IoTdevices to participate in re�ective DDoS a�acks. We �rst show thathousehold devices can be exposed to Internet re�ection even if theyare secured behind home gateways. We then evaluate eight house-hold devices available on the market today, including lightbulbs,webcams, and printers, and experimentally pro�le their re�ectivecapability, ampli�cation factor, duration, and intensity rate for TCP,SNMP, and SSDP based a�acks. Lastly, we demonstrate re�ectiona�acks in a real-world se�ing involving three IoT-equipped smart-homes, emphasising the imminent need to address this problembefore it becomes widespread.ACM Reference format:Minzhao Lyu†, Daniel Sherra�†, Arunan Sivanathan†,Hassan Habibi Gharakheili†, Adam Radford?, Vijay Sivaraman†. 2017.�antifying the Re�ective DDoS A�ack Capabilityof Household IoT Devices1. In Proceedings of WiSec ’17 , Boston, MA, USA,July 18-20, 2017, 6 pages.DOI: 10.1145/3098243.3098264

1 INTRODUCTION�e �rst wide-scale a�ack that involved home IoTs was uncoveredin early 2014 [15] – hackers broke into more than 100,000 consumerdevices including TVs and fridges to target enterprises and indi-viduals worldwide with malicious emails. Over the past year, wehave routinely seen IoT devices leveraged to launch DDoS a�acks–weaponisation of IoTs has led to 558 a�acks generating sustained1Funding for this project was provided by the Australian Research Council (ARC)Linkage Grant LP150100666

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor pro�t or commercial advantage and that copies bear this notice and the full citationon the �rst page. Copyrights for components of this work owned by others than ACMmust be honored. Abstracting with credit is permi�ed. To copy otherwise, or republish,to post on servers or to redistribute to lists, requires prior speci�c permission and/or afee. Request permissions from permissions@acm.org.WiSec ’17 , Boston, MA, USA© 2017 ACM. 978-1-4503-5084-6/17/07. . .$15.00DOI: 10.1145/3098243.3098264

tra�c over 100 Gbps, o�en peaking at 800 Gbps, representing anannual growth of 150% in frequency and 60% in size [1]. �esea�acks are cumulatively estimated to impose an hourly cost of$30,000 to the victim organisation [16].Many of these large-scale a�acks [19, 23] have paralyzed popu-lar Internet services (such as the DynDNS provider in the U.S.)by hijacking thousands of Internet accessible IoT devices (such ascameras), injecting malware (e.g. Mirai) into these devices andturning them to botnets that �ood unwanted tra�c to servers. �ishas to-date been easy because many IoT devices are shipped withli�le or no hardening against a�acks; for example, they o�en allowremote access via SSH or FTP protocols, and use insecure defaultcredentials (e.g. combination of ‘root’ and ‘admin’) that are notmodi�ed by the user. Moreover, several of these IoT devices areopenly accessible on the Internet, and are not secured behind NATor Firewall gateways [11]. Slowly, manufactures are reacting tothe growing threat of IoT bonets, and are starting to limit or blockremote access to their devices, raising the barrier for a�ackers toin�ltrate these devices for the purpose of injecting malware thatcan launch a�acks.Even if an IoT device is not compromised, it can be employed inan “re�ection” a�ack, whereby the a�acker sends it a short querymessage (such as SSDP m-search, SNMP get-next/get-bulk, or TCPsyn) with a spoofed source IP address, to which the device respondswith a long reponse to the victim. In e�ect, the a�acker uses theIoT device to re�ect the a�ack, while amplifying the volume toin�ict greater damage on the victim. Arbor Networks reports thatre�ection techniques (using SSDP, NTP, DNS, and SNMP) havealready been used in several massive DDoS a�acks [2, 3], and thegrowing ubiquity of IoT makes them a�ractive to a�ackers seekingto amplify their a�acks.What is particularly scary about re�ection a�acks is that unlike abotnet, the a�acker does not need to hijack the IoT device for there�ection a�ack – all they need is to be able to send it a spoofedquery message to which it will respond. �e aim of this papertherefore is to conduct a reality check on the feasibility and e�-cacy of re�ective DDoS a�acks, using a range of techniques on anumber of consumer IoT devices available in the market today. Our�rst contribution addresses the complacency around NAT/�rewallprotection in home networks – we show that malware (in the formof computer code, browser script, and mobile app) can penetratethe home to identify the IoT devices within, and recon�gure the

1

WiSec ’17 , July 18-20, 2017, Boston, MA, USAMinzhao Lyu†, Daniel Sherra�†, Arunan Sivanathan†,

Hassan Habibi Gharakheili†, Adam Radford?, Vijay Sivaraman†

Smart Home

Attacker’s Server

Internet

home gateway

Victim

Malware- Infected Device

3 2

1

4

5

Figure 1: Internal source of attack tra�c

home gateway to expose these IoT devices to internal and externalre�ection without the user’s knowledge, in e�ect making everyhome device a potential re�ector. Our second contribution is topro�le the re�ective capability of eight consumer IoT devices avail-able today, in terms of their ampli�cation factors, tra�c capacity,and sustained durations for SSDP, TCP, and SNMP-query baseda�ack tra�c. Our third contribution is to deploy these IoT de-vices in three homes equipped with di�erent IoT devices, usingdi�erent models of home gateways, and served by di�erent ISPs, todemonstrate their combined capability to amplify a DDoS a�ack bya factor of 20 over a sustained 24-hour period. Our work is the �rstto empirically evaluate the risk of re�ection DDoS a�acks usinghousehold IoT devices, pointing to the urgent need to identify andmitigate them before they cause widespread damage.�e remainder of the paper is organized as follows: §2 summarizesrelevant prior work on DDoS a�acks. In §3 we show how malwarecan penetrate the NAT/�rewalls in home gateways to expose house-hold IoT devices as re�ectors, while in §4 we quantify the strengthof re�ective DDoS a�acks from numerous consumer IoT devices.We demonstrate the aggregation of re�ection a�acks from our labsetup as well as three households and quantify its performance in§5, and conclude the paper in §6.

2 RELATEDWORKMethods for re�ective DDoS a�acks have been studied in the re-search literature. �e work in [6, 24] identifes 14 di�erent UDP-based protocols related to network services (SSDP, SNMP, DNS,NTP, NetBios), legacy protocols (CharGen, QOTD), P2P (BitTorrent,Kad) and Gaming (�ake 3, Steam) that can be re�ected and ampli-�ed. Kuhrer et al [12] scan and discover publicly accessible Internetdevices, including servers, home routers, and embedded devicesthat respond to UDP re�ection requests. �e work is extended in[14] to include a�acks based on 13 common TCP-based protocols(FTP, HTTP, IPP, IMAP, SSH, etc.) – and about 2% of over 20 millionhosts scanned on the Internet were found to have an ampli�cationfactor greater than 20x.

Smart Home

Malware- infected Device

Attacker

Botnet Devices

Internet

home gateway

Victim

4

3

2

1

6 5

Figure 2: External source of attack tra�c

Prior works have only considered re�ection agents publicly accessi-ble over the Internet, while we additionally show that consumer IoTdevices secured behind home gateways can also be exposed. Fur-ther, prior works have largely focused on measuring re�ections ofsingle packets, while we quantify sustained a�acks from individualIoT devices as well as aggregated households.

3 EXPOSING HOUSEHOLD IOT DEVICESAS REFLECTORS

A�ackers today commonly use publicly available services such asDNS and NTP as re�ectors [13]. While the high tra�c capacityof such servers makes them a�ractive as re�ectors, their limitednumber makes them easier to safeguard. By contrast, household IoTdevices individually have low tra�c capacity, but their aggregationin large numbers can easily sustain very high a�ack volumes, mak-ing them a�ractive agents for the next wave of re�ection a�acks.�e presence of home gateways with NAT/Firewall o�ers some pro-tection to household IoT devices from being used as re�ectors, butin this section we show that this protection can be circumventedrelatively easily, making real the risk that tens of millions of suchdevices can become re�ection agents.Our a�ack is inspired by prior work that has shown that it isrelatively easy to inject malware into downloaded so�ware [18],browser plug-ins [9], and mobile apps [8], that the user can rea-sonably be expected to be running within their home inside of thehome gateway. Speci�cally, [9] has shown that malicious scriptscan be embedded in browser extensions to send packets on thehome network, and [20] has shown that a malicious mobile app(approved by Apple) can discover IoT devices within the home andcon�gure port forwarding on the home gateway to allow externalaccess to these devices. We now describe two methods by whichsuch malware can expose household IoT devices as re�ectors toa�ackers.�e �rst (and somewhat naive) method is depicted in Fig. 1. In step1© our malware scouts for re�ection-vulnerable UDP ports (1900SSDP, 161 SNMP) and common TCP ports (22 SSH, 23 Telnet, 80

2

�antifying the Reflective DDoS A�ack Capabilityof Household IoT Devices2 WiSec ’17 , July 18-20, 2017, Boston, MA, USA

Device Type SSDP Re�ection SNMPv1 Re�ection SNMPv2c Re�ection TCP SYN Re�ectionSamsung smart cam Unsupported Unsupported 4.65 5Wemo power switch 24.44 Unsupported Unsupported 5Philips Hue lighbulb 15.13 Unsupported Unsupported 6Belkin NetCam 43.3 Unsupported Unsupported 6HP ENVY 5540 printer Unsupported 1.33 Unsupported 5Wemo motion sensor 27.47 Unsupported Unsupported 5Smart�ings hub Unsupported Unsupported Unsupported 4Withings Smart sleep sensor Unsupported Unsupported Unsupported 6

Table 1: Protocol vulnerability and ampli�cation factors

HTTP, 443 HTTPS) on IoT devices that are present in the home net-work. It then transfers collected information to the outside a�ackerin step 2©. Upon receiving a trigger message from the a�acker (step3©), our malware in step 4© becomes part of the botnet that gener-ates IP-spoofed tra�c (by forging the packet header so it containsa victim’s address as sender) to IoT devices inside the local homenetwork. �e IoT devices will respond (step 5©) to amplify andre�ect these packets to the victim machine in the Internet.�ough the a�ack above is feasible (as demonstrated later in thispaper), it has some limitations. Firstly, IP-spoo�ng is not possible insome platforms – for instance, Apple iOS does not allow developersto access and modify raw packet information. Secondly, this a�ackrelies on the insider botnet device (containing the malware) to bepresent and online in the home network. On the �ip side, the re�ec-tion sourced from an internal botnet can be quite e�cient since anUDP-based query can be broadcasted to multiple IoT devices in thehome network, triggering them all to reply to the victim, therebyachieving high ampli�cation.A more sophisticated version of our a�ack is shown in Fig. 2, whichrequires an one-o� action from the malware to identify and ex-pose household IoT devices to external botnets. �e malware �rstdiscovers IoT devices in the house (step 1©) as before. It then re-con�gures the home gateway using an UPnP SOAP command (step2©) to enable port-forwarding, so that query packets from the In-ternet get forwarded to a speci�c port of appropriate IoT devicein the home that responds to (and ampli�es) the query. �is willbe demonstrated in subsequent sections for multiple IoT devicesacross multiple home gateway models. Our malware then informsthe a�acker in step 3© on the public IP address, protocols and portnumbers to use for re�ecting a�acks from this house. �e a�ackerinstructs botnet devices (step 4©) to source tra�c towards this house(step 5©), which the household IoT devices now amplify and re�ectto the victim on the Internet (step 6©).

4 QUANTIFYING THE REFLECTIONCAPABILITY

We evaluate tra�c re�ection using the a�ack models presented inthe previous section applied to eight consumer IoT devices: theseinclude the Samsung smart camera[21], Wemo power switch[5],Wemomotion sensor[5], Philips Hue lighbulb[17], BelkinNetCam[4],HP ENVY 5540 printer[10], Smart�ings hub[22], and WithingsSmart sleep sensor[25], all chosen as they have fairly high adoptionamong consumers today. In our laboratory setup all IoT devicesare connected to a TP-Link home router model Archer C7 v2 that

runs OpenWrt �rmware release Chaos Calmer (15.05.1, r48532) andserves as the gateway to the Internet. We wrote Python script thatemulates the malware, running on a Macbook Air laptop connectedto the LAN side of the home router. Our a�acker is an Ubuntumachine (running a PHP script), the victim is a Windows7 laptop,and the external botnet device is a Kali Linux desktop (runningpython script), all of which are directly connected to the campusnetwork o�ering public IP addresses.

4.1 Attack Ampli�cationOur �rst a�ack is from the internal botnet, which sends a broadcastM-SEARCH request for SSDP, and get-next request for SNMPv1 (asbroadcast request), get-bulk request for SNMPv2c (as broadcastrequest), and unicast SYN packet for TCP. For the TCP re�ectionscenario, we inhibit the victim from sending a RST packet to there�ector (which is the likely case when it is overloaded with DDoSa�ack tra�c [14]), which makes the re�ector retransmit the TCPSYN-ACK repeatedly (4-6 times for the IoT devices we used).

Each IP-spoofed packet generated by the botnet device causesone (in the case of SNMP) or many (in the case of SSDP and TCP)packets to get re�ected to the victim. Table 1 shows re�ection types(SSDP re�eciton, SNMPv1 re�ection, SNMPv2c re�ection and TCPSYN re�ection) supported by each IoT device considered, alongwith their ampli�cation factor where applicable, which is the ratioof size(s) of re�ected packet(s) to the size of the original spoofedrequest packet. It is seen that all eight IoT devices considered canre�ect TCP SYN packets, though the ampli�cation factor is rela-tively low in the range of 4-6 (arising from retransmissions of theSYN-ACK). SNMP is re�ected by only two of eight devices considered,again with a relatively low ampli�cation factor, with the SNMPv2get-bulk being more e�ective than the SNMPv1 get-next request.SSDP, supported by half the devices considered, by far yields thehighest ampli�cation: for example the Belkin NetCam and Wemomotion sensor amplify a�acks by factors of 43.3 and 27.47 respec-tively. �is is because the SSDP response typically contains deviceinformation including IP address, name, UUID, management URL,functionalities, etc.; this information can vary among devices, forexample the Philips Hue lightbulb’s response is about one third ofthe Belkin NetCam’s in bytes.We also veri�ed that the same a�acks work from an external botnet,once the malware has cra�ed UPnP packets to enable port forward-ing on the home gateway. �e ampli�cation factors are identical,the only di�erence being that in the case of SSDP and SNMP the

3

WiSec ’17 , July 18-20, 2017, Boston, MA, USAMinzhao Lyu†, Daniel Sherra�†, Arunan Sivanathan†,

Hassan Habibi Gharakheili†, Adam Radford?, Vijay Sivaraman†

Time (sec)0 100 200 300 400 500 600

Re

flect

ed

ra

te (

Kb

ps)

-5

0

5

10

15

20Input rate: 0.5 KbpsInput rate: 1 Kbps

Figure 3: Re�ected SSDP tra�c pattern of Philips Hue light-bulb

Time (sec)0 100 200 300 400 500 600

Re

fle

cte

d r

ate

(K

bp

s)

0

50

100

150

200

250

300

350Input rate: 10 KbpsInput rate: 13 Kbps

Figure 4: Re�ected SSDP tra�c pattern of Wemo powerswitch

M-SEARCH, get-next,get-bulk requests have to be unicast mes-sages (addressed to the home gateway’s public IP address on theappropriate port) rather than a LAN broadcast.

4.2 Sustaining AttacksIoT devices are resource-constrained, and we do not expect themto be able to amplify arbitrary volumes of a�acks. In this sectionwe therefore quantify the maximum rate and duration for whicheach IoT device can sustain a re�ection a�ack. We subject eachIoT device to bombardment of a�ack tra�c at various rates for aduration of 10 minutes (by adjusting the inter-packet delay andusing multi-threading where needed), and observe how its re�ectedtra�c pa�ern and ampli�cation change with time and tra�c rate.

UDP-based Re�ection: One may note from Table 1 that eachIoT device considered supports at most one of the UDP protocols

Avg. rate generated by botnet (Kbps)0 5 10 15 20

Avg

. ra

te r

ece

ive

d b

y vi

ctim

(K

bp

s)

0

100

200

300

400

500

600

700

800BelkinNetCamWemoSwitchWemoSensorPhilipsLightbulb(Y*10)HPPrinterSamsungWebCam(X/10)

Figure 5: Input/Output average rate in sustained UDP re�ec-tion attack

Avg. rate generated by botnet (Kbps)0 10 20 30 40 50 60 70

Avg

. ra

te r

ece

ive

d b

y vi

ctim

(K

bp

s)

0

20

40

60

80

100

120

140

160

180WhitingsSleepSensorSamsungWebcamBelkinNetcamPhilipsLightBulbWemoSwitchWemoSensor(Y*10)HPPrinterSmartThingsHub(Y*10)

Figure 6: Input/Output average rate in sustained TCP re�ec-tion attack

(SSDP or SNMP). We therefore subject these devices to the appro-priate UDP tra�c at increasing rate. Fig. 3 shows a time-series ofthe re�ected rate from the Philips Hue lightbulb when subjected totwo SSDP query rates: when the request rate is 0.5 Kbps, it re�ectsat around 5 Kbps (dashed red line in plot) and when subject to 1Kbps it re�ects at 12 Kbps (solid blue line). �e resulting sustainedampli�cation is therefore around 10-12, which is slightly lower thanthe ampli�cation of 15 obtained from a single packet (as reportedin Table 1, signifying that the e�cacy of ampli�cation can fall athigher rates. Indeed, when we increased the query rate above 1Kbps, the re�ected tra�c rate and tra�c pa�ern over time do notchange, signfying that the device has saturated in its ability to sus-tain the rate.In Fig. 4 we show the re�ected tra�c pa�ern from the Wemo powerswitch when subjected to SSDP queries. When the query rate isaround 10 Kbps, the device is able to sustain a re�ection rate ofaround 220 Kbps, corresponding to an ampli�cation factor of around

4

�antifying the Reflective DDoS A�ack Capabilityof Household IoT Devices3 WiSec ’17 , July 18-20, 2017, Boston, MA, USA

Time (Minutes)0 10 20 30 40 50 60

Thro

ug

hput (M

bp

s)

0

0.2

0.4

0.6

0.8

1

1.2

1.4

Victim (external botnet)Botnet (external botnet)Victim (internal botnet)Botnet (internal botnet)

Figure 7: Aggregated attack tra�c from external and inter-nal botnets

22 (consistent with the number of 24 reported on a per-packet basisin Table 1). However, in this case increasing the query rate furthercauses the device to falter – the �gure that at an input rate of 13Kbps, the device re�ects tra�c for only about 30 seconds before itbecomes unresponsive (itself becoming a victim of a DoS a�ack!),and requires around 100 seconds to recover back before the cyclerepeats. As astute a�acker would know the rate to which a devicecan be pushed so as to sustain the DDoS a�ack over longer periods.Fig. 5 summarizes the ability of each IoT device considered to sus-tain a�acks, by plo�ing the average re�ected tra�c rate (receivedby victim) as a function of the average input tra�c rate (generatedby botnet) – the slope of each curve is indicative of the ampli�cationfactor. Devices such as the Samsung SmartCam (using SNMPv2c),Philips lightbulb (using SSDP), and HP printer (using SNMPv1)saturate in their ability to re�ect a�acks (at respective input ratesof 140, 0.7 and 15 Kbps), while other devices such as the BelkinNetcam, Wemo motion sensor, and Wemo power switch (all usingSSDP) drop markedly in their rate when subject to input tra�c inexcess of 13, 10, and 10 Kbps respectively.

TCP-basedRe�ection: Table 1 indicates that a TCP SYNpacketsent to an IoT device gets ampli�ed by a factor of 4-6. However, ex-perimentation revealed that six of the eight IoT devices consideredcould not sustain even a few Kbps of TCP SYN requests, and theirre�ected a�ack rates never exceed 20 Kbps (i.e. Smart�ings hub,Wemo power switch, Wemo motion sensor, Samsung SmartCam,Belkin Netcam and Philips Light Hue bulb are not able to generatesustained a�ack rates more than 0.3, 0.7, 0.8, 1.9, 13 and 16 Kbpsrespectively), as depicted in Fig. 6. �is is because these IoT devicesare not able to maintain more than a few concurrent connectionsopen, possibly because their memory resources get exhausted, andsize of each TCP SYN-ACK packet is relatively small (i.e. aboutseveral tens of Bytes). �e �gure also shows that the HP Printer(black do�ed line) and the Whithings sleep sensor (green do�edline) are the only ones that can sustain higher re�ection rates; how-ever, their ampli�cation factors when re�ected average rates exceed

House Two

Attacker

Internet

Victim Botnets

TP-Link WR1043ND

SmartThings Hub Wemo Sensor

Wemo Switch

House Three

House One

ASUS DSL-N55U

Netgear DGN2000

Philips Light Hue Bulb

Samsung SmartCam

Withings Sleep Sensor

HP ENVY 5540 Printer Belkin NetCam

AARNET

TPG

Telstra

Figure 8: Residential deployment

Time5pm 11pm 5am 11am 5pm

Thro

ughput (M

bps)

0

0.2

0.4

0.6

0.8

1

1.2

1.4

botnet ↑

home1 ↓

home3 ↓

home2 ↑

victim ↓

Figure 9: Re�ected aggregated tra�c pattern

20 Kbps (approximately 2 and 1 respectively) are much lower thanexpected from Table 1, indicating that the state maintenance inTCP imposes a higher burden on the IoT device, leading to muchlower ampli�cation for TCP compared to UDP tra�c. A�acks usingUDP are therefore more e�ective, except when the IoT device doesnot support any UDP re�ection (such as the Smart �ings hub andWhithing sleep sensor).

5 AGGREGATED REFLECTIVEDDOS ATTACK

Having quanti�ed the individual re�ection capabilities of the eightconsumer IoT devices, we deployed them in aggregate, �rst in thelab, and then distributed across three homes (belonging to authorson this paper), in order to validate their combined behavior in thereal-world.

5

WiSec ’17 , July 18-20, 2017, Boston, MA, USAMinzhao Lyu†, Daniel Sherra�†, Arunan Sivanathan†,

Hassan Habibi Gharakheili†, Adam Radford?, Vijay Sivaraman†

5.1 Lab EnvironmentAll eight IoT devices are connected to a home gateway in our lab,and a�ack tra�c is generated �rst from internal and then fromexternal botnets. �e internal botnet is able to broadcast its SSDPqueries (to address 239.255.255.250) and SNMP v1/v2c requests(to address 192.168.0.255 in our setup), while for the external bot-net appropriate port forwarding rules are enabled by the malwareto direct queries as unicasts to each device. For the SSDP re�ec-tion, the standard M-SEARCH is a broadcast request, our botnetdevice instead sends unicast UDP packets with the same payload asM-SEARCH request to get it routed to the home gateway. We didnot make an overly great e�ort to optimize the query rates to eachspeci�c device – our results in the previous section indicate thatevery device we considered can sustain input tra�c of 10 Kbps, sowe kept the rate uniform at this number for UDP and TCP requestsacross all devices.In Fig. 7 we show the average re�ected tra�c rate received by thevictim (a computer on campus) over an 1-hour period, and �nd it tobe roughly 1.1 Mbps for both internal and external botnet a�acks.�e external botnet tra�c rate is around 50 Kbps (corresponding toan ampli�cation of over 20), while the internal botnet rate is a lotlower at 20 Kbps, since it broadcasts its queries on the home LAN,giving it a higher ampli�cation factor of over 100.

5.2 Residential EnvironmentWe now distributed our IoT devices across three households (be-longing to the authors), as depicted in Fig. 8, each having a di�erenthome gateway (ASUS, Netgear, and TP-Link) and a di�erent ISP.Python scripts were executed in each household to emulate themalware that discovered available re�ective ports of householddevices and enabled port forwarding on the respective gateways,and the a�acker was hosted on an Ubuntu machine, a Kali Linuxmachine located on campus representing an external botnet device.Fig. 9 shows the tra�c sourced from the botnet device (the bo�omblack line, averaging at just under 60 Kbps), and the tra�c re�ectedfrom each of the three houses to the victim was measured (home-1green line 0.14 Mbps, home-2 light-blue line 0.42 Mbps, home-3dark-blue line 0.6 Mbps), and found to total 1.16 Mbps (top red line).Further, this ampli�cation of around 20 was sustained for 24 hoursfrom 5pm on 6 Feb 2017 till 5pm on 7 Feb 2017.

6 CONCLUSIONS�is paper has explored the feasibility and e�cacy of DDoS a�acksthat use consumer IoT devices as re�ectors. We have shown thathome gateways can be bypassed by malware inside the home to ex-pose IoT devices as re�ectors to external botnets. We have pro�ledthe re�ective power of eight popular consumer IoT devices in termsof their ampli�cation factors and sustained rates. We have deployedthese IoT devices in real homes to amplify an a�ack by a factor of20 to in�ict 1.2 Mbps of unwanted tra�c on an Internet victim for24 continuous hours. It is not inconceivable in the near future that8 million (rather than just eight) IoT devices, mistakenly assumedto be safely hidden behind NAT gateways, are used as re�ectors toin�ict damage on victims in the form of Terabit-per-second DDoS

a�acks. While we cannot pro�er a ready solution, a�empts at lim-iting the network behavior of IoT devices [7] are worth considering.

REFERENCES[1] Arbor Networks. 2017. Insight into the Global �reat Landscape. h�ps://www.

arbornetworks.com/insight-into-the-global-threat-landscape. (2017).[2] Arbor Networks. 2017. No end in sight for DDoS a�ack size

growth. h�ps://pages.arbornetworks.com/rs/082-KNA-087/images/WISR Infographic NoEndInSight FINAL.pdf. (2017).

[3] B. Prince. 2015. DDoS A�acks Using SSDP Spike in Q1: Arbor Networks. h�p://www.securityweek.com/ddos-a�acks-using-ssdp-spike-q1-arbor-networks.(2015).

[4] Belkin International, Inc. 2017. NetCam HDWi-Fi Camera with Night Vision.h�p://www.belkin.com/au/F7D7602-Belkin/p/P-F7D7602. (2017).

[5] Belkin International, Inc. 2017. Wemo Switch + Motion. h�p://www.belkin.com/au/p/F7C027au/#Features. (2017).

[6] C. Rossow. 2014. Ampli�cation Hell: Revisiting Network Protocols for DDoSAbuse. Network and Distributed System Security Symposium (2014).

[7] Cisco Systems. 2016. Manufacturer Usage Description Framework. h�ps://tools.ietf.org/pdf/dra�-lear-mud-framework-00.pdf. (2016).

[8] A. P. Felt, M. Fini�er, E. Chin, S. Hanna, and D. Wagner. 2011. A Survey ofMobile Malware in the Wild. Proceedings of the 1st ACM Workshop on Securityand Privacy in Smartphones and Mobile Devices (2011), 3–14.

[9] S. Heule, D. Ri�in, A. Russo, and D. Stefan. 2015. �e Most Dangerous Codein the Browser. Proceedings of the 15th USENIX Conference on Hot Topics inOperating Systems (2015), 23–23.

[10] HP Development Company, L.P. 2017. HP ENVY 5540 Wireless All-in-OnePrinter. h�p://store.hp.com/ukstore/merch/product.aspx?opt=ABU&sel=prn&id=J6U66A. (2017).

[11] J. Condli�e. 2016. How the Internet of �ings took downthe internet. h�ps://www.technologyreview.com/s/602713/how-the-internet-of-things-took-down-the-internet/. (2016).

[12] M. Kuhrer, T. Hupperich, C. Rossow, and T. Holz. 2014. Exit from Hell? Reducingthe Impact of Ampli�cation DDoS A�acks. Proceedings of the 23rd USENIXConference on Security Symposium (2014), 111–125.

[13] L. Constantin. 2014. A�ackers use NTP re�ection in huge DDoSa�ack. h�p://www.computerworld.com/article/2487573/network-security/a�ackers-use-ntp-re�ection-in-huge-ddos-a�ack.html. (2014).

[14] M. Kuhrer and T. Hupperich and C. Rossow and T. Holz. 2014. Hell of a Hand-shake: Abusing TCP for Re�ective Ampli�cation DDoS A�acks. USENIX Work-shop on O�ensive Technologies (2014).

[15] Market Watch. 2016. Proofpoint uncovers Internet of�ings (IoT) cybera�ack. h�p://www.marketwatch.com/story/proofpoint-uncovers-internet-of-things-iot-cybera�ack-2014-01-16. (2016).

[16] Arbor Networks. 2017. DDoS: �e Stakes Have Changed. Have You? TechnicalReport.

[17] Philips Lighting B.V. 2017. Philips Hue bridge. h�p://www2.meethue.com/en-au/productdetail/philips-hue-bridge. (2017).

[18] N. Provos, D. McNamee, P. Mavrommatis, K. Wang, and N. Modadugu. 2007. �eGhost in the Browser Analysis of Web-based Malware. Proceedings of the FirstConference on First Workshop on Hot Topics in Understanding Botnets (2007), 4–4.

[19] S. Khandelwal. 2016. Friday’s massive DDoS a�ack came from just 100,000hacked IoT devices. h�p://thehackernews.com/2016/10/ddos-a�ack-mirai-iot.html. (2016).

[20] V. Sivaraman, D. Chan, D. Earl, and R. Boreli. 2016. Smart-Phones A�ackingSmart-Homes. Proc. ACM WiSec (2016).

[21] SmartCam. 2017. SmartCam Products: SNH-P6410BN. h�ps://www.samsungsmartcam.com/web/. (2017).

[22] Smart�ings, Inc. 2017. Samsung Smart�ings Hub. h�ps://www.smar�hings.com/works-with-smar�hings/hubs-and-kits/samsung-smar�hings-hub. (2017).

[23] T. Seals. 2017. Leet IoT Botnet Bursts on the Scene with Mas-sive DDoS A�ack. h�ps://www.infosecurity-magazine.com/news/leet-iot-botnet-bursts-on-the-scene/. (2017).

[24] United States Computer Readiness Team. 2014. UDP-based ampli�cation a�acks.h�ps://www.us-cert.gov/ncas/alerts/TA14-017A/. (2014).

[25] Withings SA. 2017. Sleep Sensor Accessory. h�ps://www.withings.com/fr/en/products/aura/sleep-sensor-accessory. (2017).

6