Analyzing the Propagation of IoT Botnetsfrom DNS Leakage

Anonymous Author(s)

ABSTRACTMirai and Hajime are two large botnets that came to prominencein the Fall of 2016, notably due to Mirai’s launching of several largeDDoS attacks. The propagation method of the two botnets is similar,drawing upon poor security measures in IoT devices. While reverse-engineering efforts have detailed the propagation logic, measuringthe actual growth of each botnet remains difficult, with currentmethods based on honeypot traffic analysis.

This paper presents an alternative method for measuring themacro behavior of Mirai and Hajime that is based on failed infectionattempts that leak into the DNS requests of the intended victim.This unexpected backscatter is due to the subtleties of a remotecode execution vulnerability that Mirai and Hajime exploit for prop-agation. We analyze the growth and behavior of the two botnetsusing passive DNS collection at a root nameserver, and using ac-tive measurements taken by participating in the BitTorrent DHT,which Hajime uses to help disseminate its payloads. In contrast tohoneypots, our methods provide a unique longitudinal and globalview of the botnets’ evolution.

1 INTRODUCTIONThe proliferation of the Internet of Things (IoT) has resulted ina sudden increase in the number of network-connected devicesin people’s homes, spanning devices such as network-accessiblewebcams to network-controllable light bulbs and thermostats. IoTis intended to be a boon for users, promising unprecedented inter-operability and control.

However, IoT is also proving to be a boon for attackers. Recentevents have demonstrated that many IoT devices are subject to rel-atively straightforward attacks. Notably, one of the primary attackvectors of the Mirai botnet is to log into open telnet servers on IoTdevices that still use default passwords. The combination of theease of infection with the fast proliferation of IoT devices has led tolarge botnets and powerful attacks. In 2016, the Mirai botnet wasused to launch some of the largest recorded DDoS attacks in history,including a 623Gbps attack [2] against krebsonsecurity.com, anda 1.2 Tbps attack [6] against Dyn, a large DNS provider.

In the wake of the release of Mirai’s source code, an interestingnew botnet named Hajime was released late in 2016 [1, 7, 9]. Hajimeexploits the same attack vectors as Mirai (see Section 2), but it hasseveral key differences that indicate a higher level of sophisticationthan its predecessor. For instance, rather than make use of a central-ized command and control (C&C) infrastructure, Hajime makes useof existing peer-to-peer infrastructure—the BitTorrent distributedhash table (DHT)—that its bots use to determine from whom todownload new C&C commands.

Although there have been several honeypot-based studies ofHajime [1, 7], little is known about its novel network dynamics.In particular, these prior studies focused on short periods of time,

and because of their nature as honeypots, are only able to see whoattacked them, providing narrow insight into the overall attackpatterns or rates of attack.

In this paper, we develop novel datasets that allow us to performa global and longitudinal analysis of Hajime and, to a lesser extent,Mirai. Our key insight, at a high level, is as follows: Hajime makesuse of a buffer overflow vulnerability in how some devices processNTP servers in particular configuration files: a vulnerable hostwill run the injected command, which includes a wget or tftp tothe attacker’s IP address. However, a non-vulnerable host will notoverrun its buffer, and will instead treat the shell injection as adomain name. When it issues a DNS query for this domain name,the query itself will contain the attacker’s IP address, and it will bean invalid domain name. As a result, the DNS query will be sentto a root DNS server—a “last-resort” server in DNS that is taskedwith serving queries for unknown top-level domains (TLDs).

Our dataset comprises passive packet captures to one of the rootDNS servers.1 This root server is replicated across over 100 sitesthroughout the world, and has been collecting sampled query datafor years, well before the emergence of Hajime. We complementand cross-validate our passive DNS dataset with active scans of theP2P distributed hash table (DHT) that Hajime uses to disseminateits attack payloads in a decentralized manner.

With these datasets, we are able to see millions of instances inwhich non-vulnerable hosts are targeted for attack, the IP addressof the targets’ local DNS resolver, and the IP address of the hostattacking them. This offers a unique view into the spread of a botnet:rarely is it the case that one can track attempts against the safetargets.

We analyze this data to provide accurate, longitudinal analysisof the network dynamics of the Hajime botnet. Compared to priorstudies [1, 7], we are able to identify an order of magnitude moreHajime bots. We use our datasets to investigate a wide swath ofHajime’s characteristics, including: the number of active bots overtime, their rate of infection, the geographic spread of their infection,and the bots’ lifetimes.We also correlate Hajime’s use of the peer-to-peer DHT with the botnet activity we observe through our passiveDNS data.

In sum, we make the following contributions:

• We present a novel dataset that provides insight into thespread and activity of vulnerable hosts and how non-vulnerablehosts are targeted.

• We present the first longitudinal analysis of an advancedP2P-based IoT botnet, Hajime, and compare it to its prede-cessor, Mirai.

• We cross-validate our findings with active scans of theDHT that Hajime uses to disseminate its payloads.

1We do not mention which root server so as to preserve the anonymity of this papersubmission.

1

Anonymous submission #884 to ACM CCS 2017

The rest of this paper is organized as follows. In Section 2, wedescribe the Mirai and Hajime botnets and detail the vulnerabilitythat we are able to track, and how we use it to obtain our passiveDNS datasets. In Section 3, we describe our data collection method-ology and our datasets. We analyze the size, location, and churn ofHajime bots in Section 4, and their attack patterns and targets inSection 5. In Section 6, we analyze Hajime’s use of the BitTorrentDHT, and discuss attacks that relying on the DHT exposes Hajimeto in Section 7. Finally, we conclude in Section 8.

2 BACKGROUNDIn this section, we provide an overview of the Mirai and Hajimebotnets. We also describe a remote code execution vulnerability thatboth botnets use to propagate, and discuss why failed exploitationattempts are observable at a root nameservers.

2.1 Mirai and Hajime OverviewThe Mirai botnet was discovered in August 2016, and the Hajimebotnet in early October 2016. Both botnets propagate by scanningthe Internet for hosts with specific open ports. Initially, the scanningbehavior was limited to Telnet; a bot would attempt to login to aTelnet service using a list of factory default username/passwordcombinations, and once logged in, would issue the commands totransfer and execute the bot binary to the victim. Over time, bothbots have added a propagation vector scanning for, and exploiting,the TR-064 service, which we describe next.

2.2 TR-064 VulnerabilityIn addition to the Telnet propagation vector, Mirai and Hajimealso propagate by exploiting a remote code execution vulnerabilityin some implementations of TR-064 [5]. TR-064 is a deprecatedtechnical report published by the Broadband Forum that specifiesthemethod for configuring a home router fromwithin the LAN. Themanagement protocol is based on SOAP over HTTP, and furthermandates that requests to change a configuration value be passwordprotected.

The enabling problem is that routers continue to run the TR-064 protocol, and moreover run the protocol without requiringauthentication for configuration changes. The specific vulnerabilityis in the implementation of the request handler for the TR-064 timeservice, which allows for the configuration of the device’s NTPclient. The following HTTP SOAP message shows a request to setthe domain name or IP address that the device should use as itsprimary NTP server.

POST /UD/act?1 HTTP/1.1Host: VICTIM_HOST:VICTIM_PORTUser-Agent: FAKE_USER_AGENTContent-Type: text/xmlContent-Length: BODY_LENGTHSOAPAction: urn:dslform-org:service:Time:1#SetNTPServers

<?xml version="1.0"?><SOAP-ENV:Envlopexmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body><u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1"><NewNTPServer1>SHELL_INJECTION</NewNTPServer1><NewNTPServer2></NewNTPServer2><NewNTPServer3></NewNTPServer3><NewNTPServer4></NewNTPServer4><NewNTPServer5></NewNTPServer5>

</u:SetNTPServers></SOAP-ENV:Body>

</SOAP-ENV:Envelope>

In an infection attempt, instead of specifying a legitimate do-main name for an NTP server, a bot will specify a sequence ofshell commands, shown above as SHELL_INJECTION. When run,the commands download a file, change the permissions of the fileto be executable, and execute the file. Once the file is executed, thevulnerable device is infected and becomes part of the botnet.

If a device is vulnerable, then the value for NewNTPServer in theSOAP message is given to the shell for interpretation. The sequenceof shell commands in the injection is either:

`cd /tmp;tftp -lX -rY -g HOST PORT;chmod 777 X;./X`

which makes a tftp connection to the attacker and downloads theremote file Y to a local file names X, or

`cd /tmp;wget http://HOST:PORT/X;chmod 777 X;./X`

which downloads the remote file X over HTTP. In both cases, HOSTand PORT are the attacker’s host and port, with HOST representedas a either a domain name or an IP address (PORT is optional).

As Mirai uses a centralized command and control (C&C), a Miraishell injection typically uses the hostname of the C&C and omitsthe port number. Hajime, however, lacks a centralized C&C, andinstead uses a peer-to-peer (P2P) architecture. As such, the Hajimeshell injections use an IP address and an ephermal port number,where the IP address is that of the bot performing the injection.

2.3 DNS BackscatterConsider what happens when the above injection attack is launchedagainst a non-vulnerable device. Safe against an overflow attempt,the device will treat the SHELL_INJECTION as an NTP server host-name, and will thus perform a DNS lookup for its IP address. Thisinvolves sending a DNS query to its local resolver (or to a publiclyavailable open resolver), which in turn recursively issues queries onbehalf of the client. Of course, the SHELL_INJECTION lacks a validtop-level domain (TLD)—instead of .com or .org, it ends in ./Xfor some number X. In such cases that a query has an invalid TLD,local resolvers must go to a root DNS server to get an authoritativeanswer.

In other words, whenever an attacker targets a non-vulnerabledevice, this will trigger a DNS query to a root DNS server for thepayload of the attack—which includes the attacker’s IP address. Thisresulting “backscatter” effect makes it possible to track unsuccessfulinjection attempts, provided querty data from a root name serveris available.

2.4 Root NameserversThe root of the DNS hierarchy comprises 13 lettered root nameservers, A through M, and each DNS resolver bootstraps with in-formation about the addresses of each root name server. The roleof each root name server is to provide information about nameservers for valid top level domains, e.g., for all names ending in.com or .edu. Name servers that ask the root for such informationabout valid names will cache what they learn, leaving most queriesthat the root receives to be for names that are not valid or notregistered. Each letter typically comprises a set of geographically

2

Anonymous submission #884 to ACM CCS 2017

distributed replica servers reached via anycast, whereby internetrouting chooses a particular server that will reply to the query.

2.5 Hajime’s P2P NetworkFor peer-to-peer communication, Hajime makes use of BitTorrent’sdistributed hash table (DHT) overlay network. To start downloadinga file, BitTorrent clients traditionally start by retrieving a list ofpeers from a tracker, a server that tracks peers hosting the file.Trackerless Torrents do not use a centralized tracker, instead storingthis information in a DHT.

BitTorrent uses the Kademlia DHT protocol. Each node is iden-tified by a unique 20-byte Node ID. To join the DHT, a new nodemust know at least one other node that is already a member. Asa node discovers other nodes in the DHT, it stores their Node IDand IP address in a routing table. Values are mapped to a key inthe same space as the Node IDs, usually some type of hash of thevalue data. A value is stored at the k closest nodes in the DHT to itskey, where k is a system-wide replication parameter, for instance20. The distance between two identifiers in Kademlia is calculatedas a simple XOR of the two. A node storing a value periodicallylooks up the k closest nodes to the value’s key and ensures all arestoring the value.

To find a value in the DHT, a client performs a lookup of thevalue’s key. Lookup is a recursive function that proceeds as follows.If a node is storing the value for that key, it returns the value.Otherwise it forwards the lookup request to the peer with theNode ID closest to the key that the client is aware of. In BitTorrent,the values being stored in the DHT are lists of peers. The key thepeer lists are mapped to is the corresponding torrent’s info_hash,the SHA1 hash of the torrent’s metadata uniquely identifying thetorrent. Thus to start downloading a torrent, a BitTorrent clientwill lookup that torrent’s info_hash in the Kademlia DHT.

2.5.1 Kadnode. Hajime uses an additional feature fromKadNode,a DNS resolver extension built on top of Kademlia. With KadNode,a node can announce that it owns some domain name, which othernodes can then resolve to the announcer’s IP address. In the an-nounce function, KadNode will store the announcer’s IP addressmapped to the domain identifier in the DHT, meaning the k nodesclosest to the identifier will store the identifier to IP address map-ping. A node that looks up the domain identifier will then get thatIP address in return from one of those k nodes.

2.5.2 Hajime’s Protocol. Hajime uses this DNS resolution fea-ture to find peers hosting Hajime files. On being infected, Hajimebots join BitTorrent’s Kademlia DHT. It is important to note thatthis DHT is the same ring used by BitTorrent, so it is not solelypopulated Hajime bots. Periodically, bots download a config filethat directs the bot’s behavior. To find a peer hosting the config file,the bot looks up an identifier through KadNode, then attempts toconnect to each returned IP address until it successfully downloadsthe file. The identifier consists of daily time string concatenatedwith the SHA1 hash of the filename [7].

TheDHT is used to find nodes that announce the config. files. Thefiles themselves are downloaded using a direct unicast. For directP2P communication, Hajime bots use uTorrent Transport Protocol(uTP), which implements congestion control over UDP. The initial

messages of the uTP protocol exchange in Hajime exchange a key,and subsequent packets are encrypted with the RC4 stream cipher.

2.6 Related WorkThe most immediately related prior work are the studies of theHajime botnet performed by Kaspersky Labs [7], Radware [1], andSymantec [9] in the wake of the Hajime discovery. These prior stud-ies involved a combination of honeypots and reverse engineering ofthe botnet payloads. By comparison, we perform a broader study ofthe network dynamics of Hajime, introducing a novel dataset thatspans the entire lifetime of Hajime’s use of the TR-064 vulnerability,and that includes far more bots. As we demonstrate in Section 4,for instance, we are able to identify an order of magnitude morebots than prior studies.

More broadly, there have been many studies of live botnets andthe spread of malware. Staniford et al. [13] measured the quickspread of Internet worms; it turns out that Hajime differs consid-erably in that it does not appear to outpace human reaction, butrather to simply compromise as many devices as possible, and thus,as we will show, its infection rate is more modest. Stone-Gross etal. [14] took control of a botnet’s centralized C&C infrastructure fora short period of time, and used it to measure the number of botsand the various sensitive information that they report back to theirbot master. Conversely, we study Hajime longitudinally, over thecourse of months; so doing allows us to see the spread of a botnetover time. Moreover, we perform an extensive analysis of Hajime’sdecentralized C&C infrastructure, to the best of our knowledge thisis a novel feature of this botnet.

3 DATASETS AND METHODOLOGYWe make use of two novel datasets to analyze Hajime’s networkdynamics.

3.1 Passive Root DNS BackscatterOur passive DNS data set consists of sampled queries from one ofthe root DNS letters that comprises over 100 replicas in differentgeographic locations. The samples capture 20% of all queries to thesereplicas, corresponding to approximately 30K queries per second.All told, our traces include roughly one fifth of one thirteenth ofthe queries that reach root name servers in general. (The preciseratio may vary due to imbalance between letters.) Although notevery query is captured, since attacking hosts attack many targets,the attacking bot IP address and port information can (and does)appear in our dataset.

Recall that the only hosts that will trigger a DNS query afteran attack are the non-vulnerable devices. This provides a uniqueinsight into the activity of a botnet, in that it provides us with dataon attack attempts. However, it is not without its limitations. DNSquery packets are not always large enough to contain the entireattack payload; as we discuss in Section 4, some of the attackerIP addresses in the queries are truncated (fortunately, this onlyrepresents 6.2% of the queries we analyze).

3

Anonymous submission #884 to ACM CCS 2017

3.2 Active BitTorrent DHT MeasurementIn order to analyzeHajime’s novel use of an existing P2P infrastructure—as well as understand the error in the passive DNS measurements—we also perform small active measurements of the P2P network. Tothis end, we collect two datasets:

• Seeder dataset: Hajime bots download C&C configura-tion files from one another. To learn about which botsare serving it, they leverage BitTorrent’s P2P distributedhash table. In essence, Hajime bots act like “seeders” byannouncing their IP address and port, keyed by that day’sC&C configuration file. We periodically (roughly every 5minutes) download the list of these “seeders” over span ofseveral days. To mitigate any potential geographic bias, weissue these queries from 7 distinct locations.

• Leecher dataset: After downloading the list of seeders,bots open a uTP connection to them to download thatday’s configuration file, similar to BitTorrent’s “leechers.”To understand the set of active bots, we announce our ownhosts for several months’ worth of Hajime configurationfiles, and record the IP addresses and ports of the bots whoconnect to us (we do not serve any files in return). We havecollected these for several days, as well.

4 HAJIME BOTNET SIZE AND LOCATIONThe first broad set of questions we ask pertain to the overall sizeand locations of the Hajime botnet over time. Although these broadstatistics have been addressed in recent reports on Hajime [1, 7, 9],we offer a longitudinal view of Hajime’s growth and change overtime.

4.1 How large is the Hajime botnet?We begin by investigating the overall size of Hajime over time.To this end, we analyze the distinct number of full IP addresseswe obtain over time, ignoring an IP address if we are unable todetermine whether or not it was truncated. Across all of the Hajimeattack attempts we see, we obtain a total of 3,475,896 distinct IPaddress strings; 93.8% (3,278,579) of them are full IP addresses, andthe other 6.2% (215,140) contain at least three full octets. Therefore,although our results are a lower bound, we believe the error to below.

Figure 1 shows the cumulative number of distinct attacker IPaddresses that we have observed. We make three key observations.First, the initial injection attempt occurs on December 28, 2016,nearly two full weeks before Hajime began to spread. Given the gapin time, it is possible that this was part of Hajime’s initial testingphase for the tftp and wget vulnerabilities, but we are unable toconfirm this. The IP address of this first attacker was located inAmsterdam.

Second, by the end of our window of data,2 we have observed3,260,756 distinct IP attacker addresses. This is one to two orders ofmagnitude greater than what has been previously reported [1, 7, 9].

Third, the overall growth rate in Figure 1 indicates a faster initialspread followed by a smooth, nearly linear, sustained rate of growthfor months thereafter. At first glance, it may seem surprising that2We continue to collect these data, and will update the results in future versions ofthis paper.

0

0.5M

1.0M

1.5M

2.0M

2.5M

3.0M

3.5M

12/24 01/07 01/21 02/04 02/18 03/04 03/18 04/01 04/15 04/29

Cu

mm

ula

tive N

um

ber

of

Un

iqu

e A

ttackers

Date

Figure 1: Number of unique Hajime IP addresses (cumula-tive).

0

25K

50K

75K

100K

125K

12/24 01/07 01/21 02/04 02/18 03/04 03/18 04/01 04/15 04/29

Nu

mb

er

of

Un

iqu

e H

ajim

e B

ots

Date

Figure 2: Number of unique Hajime IP addresses (daily).

this does not follow the more traditional logistic growth functionthat modern worms typically have [13]. To understand this result,it is important to keep in mind that many of the attackers in theseresults were compromised before our data captured them: the attackvectors that we are able to collect were introduced months afterHajime was first observed. Thus, we are unlikely to witness theinitial propagation, but should be able to see the activity over time.

We can envision several possible explanations for the smooth-ness in the growth rate. One possible explanation for this is thatthis linear growth is by design: Hajime may be conservative inhow rapidly it spreads, favoring a slow, broad coverage over a fastspread that may harm low-resource IoT devices. As we will seein Section 5, however, some Hajime bots attack in a very bursty,consistent manner, making it unlikely that that they are particularlycautious in their rate of spread.

Another possible explanation is that we are not witnessing thespread of new Hajime bots per se, but rather the spread of whichHajime bots are employing the attack vectors we are able to see.To investigate whether this is the case, we present in Figure 2 thenumber of unique Hajime attacker IP addresses we observe on adaily basis. These results show that the new attack vector spreadat an exponential rate among infected hosts; within three days,over 100K hosts began using the tftp or wget attacks. After this

4

Anonymous submission #884 to ACM CCS 2017

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

100000

12/24 01/07 01/21 02/04 02/18 03/04 03/18 04/01 04/15 04/29

Bir

ths a

nd

Death

s p

er

Day

Date

births

deaths

Figure 3: Daily attacker churn in Hajime. “Births” denotethe first time we saw a given address, “deaths” denote thelast time.

initial spike, we observe that the overall number of daily attackersis largely consistent within the range of 75K–100K.3

Rather, as we show next, the smooth growth of Hajime can belargely attributed to its churn.

4.2 What is Hajime’s churn?A distributed system’s churn is the rate at which hosts enter andleave the system. To study churn in Hajime, we define the birth ofan attacker’s IP address to be the time at which we first observethe address. Likewise, the death of a bot is the time at which welast see its IP address in our data.

Figure 3 shows the number of births and deaths observed on adaily basis. We draw two conclusions from this data that confirmour above results. First, the rate at which bots are leaving the systemhas, as of early March 2017, overtaken the rate at which bots areentering the system. This is reflected in the slight overall downwardtrend in Figure 2 since March. Second, the birth rate changes at aroughly linear rate and does not vary widely over small windows oftime (after the initial surge). This helps explain the smooth growthin Figure 1.

To be precise, these trends reflect the variability of Hajime’s useof the exploit that appears in our passive DNS dataset; to whatextent do they reflect the variability in the number of bots them-selves? Ostensibly, Hajime bots could remain infected (and not“dead”), but shift away from using these attack vectors. For instance,one might speculate that Hajime bots launch this attack for onlyshort periods of time and then move on to another attack vectoraltogether. To evaluate this hypothesis, we present in Figure 4 thecumulative fraction of bot lifetimes (the difference in their deathdate and birth date). We see that the median lifetime of a bot is justunder 10 hours; 39% of bots appear for more than a day’s worthof data, and 17% appear for more than a month out of our nearlyfour-month trace. We therefore believe it is likely that, as of thebeginning of 2017, Hajime bots use these attack vectors regularly,and thus our datasets reflect true bot behavior and persistence.

3There appears to be a small decline at the end of this data; as we process more data,we will be able to determine whether this is a diurnal trend.

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0.0001 0.001 0.01 0.1 1 10 100 1000 10000

Cu

mu

lati

ve P

rob

ab

ilit

y

Lifetime (hours)

Figure 4: CDF of a Hajime bot’s lifetime.

Country BotsIran 1,071,399Russia 328,269Italy 295,377Pakistan 197,921India 177,682Turkey 150,127China 144,470Australia 121,571Thailand 112,023Vietnam 110,376Brazil 97,962United Kingdom 52,740France 46,308Unknown 42,812Trinidad and Tobago 25,147

Table 1: Top 15 countries by number of Hajime bots in thatcountry

Taken together, these results indicate that Hajime’s spread iscurrently on the decline; although it continues to introduce newattackers on a daily basis, it is losing bots faster than it is recovering.

4.3 Where are Hajime bots located?To understand where Hajime bots are located, we apply the Max-Mind IP geolocation database4 to each of the attacker IP addresseswe observe. Table 1 shows the top 15 countries by the numberof attacker IP addresses we have observed. Overall, these resultsshow a globally distributed set of bots, with a particularly heavyconcentration in a small number of countries.

Our results in Table 1 differ from previous honeypot-based stud-ies [1, 7], both in terms of raw number (recall that we see one to twoorders of magnitude more bots) and in terms of relative ranking ofcountries. In our datasets, Iran is by far the most prevalent attacker,constituting 32.8% of all of the unique attacker IP addresses we see,

4https://www.maxmind.com/en/geoip2-databases

5

Anonymous submission #884 to ACM CCS 2017

0

5000

10000

15000

20000

25000

30000

35000

40000

45000

12/24 01/07 01/21 02/04 02/18 03/04 03/18 04/01 04/15 04/29

Un

iqu

e H

ajim

e B

ots

Date

IranRussia

ItalyPakistan

IndiaTurkeyChina

AustraliaThailandVietnam

Figure 5: Unique Hajime bots for the top-ten countries(daily)

whereas Radware’s honeypot study found only 9% of their hostsfrom Iran. Conversely, Vietnam and Brazil have appeared in thetop three of other studies’ most prevalent countries, yet in our datathey constitute only 3.4% and 3.0%, respectively. The methodolog-ical distinction between our study and these prior studies is thatwhile they rely on fixed honeypots themselves receiving attacktraffic from compromised sources, we leverage a distributed, global“honeypot” of thousands of machines that are not vulnerable. Iran isknown to have a sophisticated system for detecting and throttlingcommunication using unknown protocols [3], and this system mayinterfere more with the attack traffic used by prior studies thanwith the DNS traffic used here.

To understand whether our overall numbers are representativeover time, Figure 5 shows the daily unique number of Hajime botsfrom each of the top ten countries from Table 1. We make four keyobservations from these results. First, it is immediately clear thatIran constitutes a large portion of the overall population; indeed,the shape of the aggregate number of bots in Figure 2 is largelydetermined by the number of Iranian bots on a given day. Second,while most countries exhibit a relatively consistent number of botsacross days, Iran and Pakistan see considerable deviation. AlthoughPakistan is ranked fourth in terms of overall bots, it had the secondmost number of bots in April 2017.

Third, there is a pronounced dip in late January 2017 that affectedmultiple countries. We have verified that this is not a measurementartifact (we collected no less data on those days than on others).Interestingly, this dip is correlated with a BrickerBot [8] attack wealso observe with our passive DNS dataset. As of this time, however,we are unable to verify the root cause.

Finally, the results in Figure 5 show that our overall countryranking is reflective of true bot activity over time. It is possiblethat the raw number of IP addresses overestimates the numberof attackers because IP addresses can (and often are) reassignedto home network addresses; sometimes on the order of every fewhours [12]. However, using RIPE Atlas probes in Iran, we verifiedthat ISPs in Iran do not appear to change IP addresses every day,

0

200000

400000

600000

800000

1e+06

1.2e+06

12/24 01/07 01/21 02/04 02/18 03/04 03/18 04/01 04/15 04/29

Inje

cti

on

s A

ttem

pts

Date

Figure 6: Hajime injections per day.

lending confidence in our results on the number of unique bots perday.

Summary The results in this section provide the most complete,longitudinal view of the Hajime botnet to date, yielding an order ofmagnitude more attacker IP addresses than previous studies. Ourmain results point to a decline in the number of daily active Hajimebots, dipping from a peak of 115K at the beginning of the year toapproximately 75K today. We find that these dynamics are largelyattributable to moderately high churn rate; tens of thousands ofnew bots are “born” every day, but a nearly equivalent amount “die.”Next, we turn our analysis to what these bots do while alive.

5 ATTACK ACTIVITYIn this section, we investigate the attack attempts made by theHajime botnet. Because our passive DNS dataset only capturesthe tftp and wget attacks, we limit our analysis to those. We alsocompare Hajime’s attack dynamics to those of Mirai.

5.1 How often do bots attack?We begin our study into Hajime’s attack behavior by looking at thedaily number of injection attempts made by Hajime over time, asshown in Figure 6. From this figure we draw three key observa-tions. First, soon after adding the attack vector to Hajime, its botsstarted employing it quickly, reaching over 400K daily injectionsattempt within three days after rollout. Second, the overall num-ber of injection attempts on a daily basis has remained quite high,peaking at nearly 1.2M attempts, but typically averaging roughly600K per day (on average roughly 7 injection attempts per activebot per day). Finally, the overall distribution reflects the numberof bots, including the two pronounced spikes in mid-February andMid-March.

Because the number of daily injection attempts tracks so wellwith the daily number of bots, this would seem to indicate a consis-tent distribution of injection attempts across bots. Figure 7 showsthe number of attacks issued by each bot as a distribution acrossall 3.2M Hajime bots in our dataset. These results indicate that thenumber of injection attempts per attacking IP address exhibits askewed distribution, with a median of 3, a 99th percentile of 126,and one IP address in France sources 28,776 attacks. Combining

6

Anonymous submission #884 to ACM CCS 2017

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1 10 100 1000 10000 100000

Cu

mu

lati

ve P

rob

ab

ilit

y

Injection Attempts

Figure 7: Distribution of the number of attack attempts is-sued per Hajime bot. (Note the x-axis is log-scale.)

this result with the fact that Hajime bot lifetimes tend to be some-what short (Figure 4) leads us to conclude that many Hajime botsenter the system, issue a small number of injection attempts, andthen depart (or, at the very least, cease to launch more tftp/wgetattacks).

This leaves the question of how more persistent, active botspattern their injection attempts: do they send in quick bursts, ordo they spread their injection attacks over time? As an evaluationmetric, we use the Kolmogorov-Smirnov (KS) test: for each attacker,we compute the CDF of the attacker’s injection attempts over thecourse of its lifetime, andwe compare it to the CDF that would occurif the bot were to spread its attacks out perfectly evenly in time. TheKS test reports the largest magnitude difference between the CDFs:a value of zero means there is no difference in the distributions (theattacks were evenly dispersed throughout the bot’s lifetime), whilea value of one in this case means the bot performed virtually all ofits attack injections at its birth date.

Figure 8 shows the distribution of these KS scores for all botsthat have lifetimes of at least 10 hours and that issue at least 10injection attempts. We make two key observations. First, 72% of thebots have a KS score near one, confirming our hypothesis abovethat many bots perform almost all of their injection attempts in abursty manner. Second, the other 28% of hosts have surprisinglylow KS scores, indicating that they take a more measured approachto attacking others. Roughly 5% of the hosts have a KS score nearzero, indicating they spread their injection attacks very evenly overtheir 10 or more hours of lifetime.

To understand from where the injection attempts originate, weshow in Table 2 the top 15 countries by the number of injectionattempts made from that country. The number of attacks from agiven country is largely a function of the number of bots within thatcountry, with some exceptions. For instance, Australia is responsiblefor the second most number of attacks, and yet has only the 8thmost bots (8.8× fewer bots than Iran, but only 3.1× fewer injectionattempts). Whether or not we obtain a given injection attempt ispartly due to the location (and latency and resolver software) of

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Cu

mu

lati

ve P

rob

ab

ilit

y

KS

Figure 8: The Kolmogorov-Smirnov (KS) score comparingthe distribution of Hajime bots’ rate of attack versus a per-fect uniform attack rate. A value of zero represents a consis-tent rate over time; a value of one represents bursty attacksall at once.

Country Injection AttemptsIran 7,773,806Australia 2,498,408Italy 2,227,875Russia 1,921,586Pakistan 1,856,696China 1,814,055Vietnam 1,809,609India 1,660,489Turkey 1,560,802Republic of Korea 1,545,808Thailand 1,202,764United States 769,120Brazil 680,073United Kingdom 529,321Trinidad and Tobago 521,882

Table 2: Top 15 countries, sorted by the number of Hajimeinjection attempts from that country

the target’s local resolver; thus, to determine whether these resultsmay be biased, we next turn to where the locations of the targetsof the attacks.

5.2 Whom does Hajime target?In reasoning about the attack targets, it is important to recall thatour passive DNS data provides us with failed attempts to non-vulnerable hosts. Thus, there will also be many injection attemptsthat succeed; because these successful attacks will create new at-tackers, we can in essence infer where the successful attacks tookplace (where the attackers are located).

We present in Table 3 the 15 countries that are targeted mostoften in our dataset. Note that these do not align with the countrieswith the most attackers—Iran does not even show up in the top 15.

7

Anonymous submission #884 to ACM CCS 2017

Country ResolversUnited States 1489France 621United Kingdom 619Russia 556Turkey 320Germany 292Australia 209Canada 200Argentina 195Vietnam 178Italy 171Brazil 158India 141Netherlands 132Philippines 132

Table 3: Top 15 countries, sorted by the number of (non-public) resolvers within that country that are targeted byHajime.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 5000 10000 15000 20000 25000

Cu

mu

lati

ve P

rob

ab

ilit

y

Distance (km)

Figure 9: Distribution of Hajime bots’ distances to the re-solver of their intended victims (not including open re-solvers).

Intuitively, the reason for this may be rooted in the fact that weare only seeing the injection attempts against the non-vulnerablehosts. This suggests that the fraction of vulnerable hosts variesconsiderably across countries. An interesting area of future workwould be to fingerprint devices on a country-by-country basis toinvestigate the relative vulnerability rates.

Having explored the most likely sources and targets of attacks,we now seek to understand how attackers and targets are paired.For each attack attempt, we IP-geolocate the attacker (whose IPaddress is in the DNS query) and the victim’s DNS resolver (thesource IP address of the DNS query), and compute the great-circledistance between them. We ignore public (“open”) resolvers—onesthat service queries for any host—in the expectation that the non-public resolvers are geographically proximal to their clients (thetargets of the attack injection) [10]. As a result, we believe these

0

5000

10000

15000

20000

25000

30000

35000

40000

11/01 12/01 01/01 02/01 03/01 04/01 05/01

Inje

cti

on

s A

ttem

pts

Date

Figure 10: Mirai injections attempts per day.

distances to be representative of the distance from attacker to target.Of the 63,094,223 total resolvers from which we receive backscatterHajime attacks, we were able to identify 15,913,183 (25.2%) of themas open resolvers; our analysis focuses on the other 47,181,040(74.8%).

Figure 9 shows the distribution of these distances. We makethree key observations. First, a sizeable fraction (5%) have an ef-fective distance of 0 km, indicating they are attacking their owncountry or even their own network. Second, there is no strict boundon the distance an attacker’s query can travel; in fact, we see somequeries travel to the opposite side of the Earth (the longest querytravels half the circumference of the Earth).

Finally, and most importantly, there does not appear to be anygeographic preference in the injection attempts. With a median of5000 km (3106 miles), attackers do not have a strong preference toremain close. Although Figure 9 does not show a uniform distribu-tion, Hajime bots may still be choosing attack targets uniformlyat random; the difference in distribution is likely due to the factthat the location of attackers is not uniformly distributed (frommost hosts, there are more targets within 3000 km than there are9,000–12,000 km away).

5.3 How does Hajime compare to Mirai?We close this section by comparing Hajime’s attack patterns tothose of its predecessor, Mirai. Because Mirai’s attack vector useshostnames instead of IP addresses, we are unable to geolocateattackers. However, we can still obtain counts of injection attemptsand geolocate the target; we analyze these both here.

Figure 10 shows the number of daily injection attempts fromMirai (to non-vulnerable hosts). Compared to Hajime (Figure 6),Mirai has far fewer injection attempts: typically by an order ofmagnitude. Mirai does not appear to be subject to the same dip inthe third week of January that Hajime is; this may indicate that itwas a Hajime-specific event, but we are unable to confirm that atthis time.

Although the raw number of injection attempts differ greatlybetween Hajime and Mirai, their targets have surprisingly simi-lar features. Table 4 shows Mirai’s top targeted countries, which,in terms of rank, tracks very similarly to Hajime’s (Table 3). Onenotable difference is that Mirai unsuccessfully targets Iran dispro-portionately more often than Hajime. It is possible that Mirai fails in

8

Anonymous submission #884 to ACM CCS 2017

Country ResolversUnited States 728United Kingdom 490Russia 378Turkey 308Germany 227France 223Italy 181Vietnam 168India 142Brazil 135Argentina 132Iran 126Australia 118Canada 112Spain 112

Table 4: Top 15 countries by number of Mirai victim (non-public) resolvers

these attempts because the Iranian nodes are already compromisedby Hajime (its most common country).

Summary The results in this section show that Hajime attemptsto infect hosts uniformly at random, and with relatively few attacksper bot on average. We note that our results in this section are astrict lower-bound, as our dataset comprises only one of the 13 rootDNS servers, and the data we get is further sampled. It is possiblethat the true rate of infection attempts is therefore 13× or morewhat we are able to directly observe. Nonetheless, our view intoinfection targets is far wider and more longitudinal than honeypot-based approaches, because of our use of the DNS “backscatter” thatarises from attacks on non-vulnerable hosts. All together, theseresults demonstrate that Hajime has truly supplanted Mirai, andcontinues to actively (attempt to) spread; as new vulnerable devicescome online, Hajime is likely to continue to proliferate.

6 COMMAND & CONTROL ACTIVITYOne of the unique aspects of Hajime is its use of an existing P2Pinfrastructure to coordinate command and control. We close ouranalysis by investigating how Hajime’s bots make use of this P2Pnetwork. More precisely, we study the bots’ activity on this net-work (how many of them join, upload, or download), not the C&Cpayloads themselves. Recall that active bots download a new config-uration file periodically. Configuration files contain pointers to newexecutable modules, which can be used to change the bot’s behaviorafter deployment. Hajime configuration filenames have a standardformat [7], which changes once per day. Configuration files are dis-tributed using the BitTorrent DHT, which implements the KademliaDHT protocol. In our experiments, we adapt the KadNode client(version 1.0.0 5) to search for seeders, and to announce configurationfiles as described below.

We structure our analysis around the role the bots play: seedershost configuration files that leechers periodically download.

5Available at https://github.com/mwarning/KadNode

6.1 Seeder activityWe begin our analysis of Hajime’s C&C by focusing on the seeders:the bots that host the configuration files that other bots download.

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

05-17 15:00 05-18 03:00 05-18 15:00 05-19 03:00 05-19 15:00

Nu

mb

er

of

Un

iqu

e S

ee

de

rs

Date

Figure 11: Number of seeders in the DHT over time.

Bots download new configuration files periodically. The set ofnodes that host new configuration files changes, and the BitTorrentDHT is used to synchronize the bots with the current “seeders”of the configuration files. We conducted periodic searches of theBitTorrent DHT for names corresponding to Hajime configurationfiles. Each peer we ran was an EC2 instance, and they were iden-tified by EC2 to be located in data centers in California, Ireland,Mumbai, Seoul, Sydney, Frankfurt, London, Sao Paulo, Singapore,and Northern Virginia. The BitTorrent DHT is built over the Kadem-lia protocol: each query uses the Lookup command, and can takeseveral minutes to complete. We issued queries at most once everyfive minutes.

Figure 11 shows the number of unique seeders we discoveredbinned into 72 minute periods. We chose that binning interval since,after the few initial searches, we received information about newnodes once every 72 minutes. (Subsequent searches during the sameepoch did not return new information.) We believe, but have notyet confirmed, that this is due to a rate limiting feature employedby BitTorrent DHT peers. Our data shows that the config files areseeded by many peers: over 2.5 days, we retrieved 42, 793 distinctseeder IP addresses, with 2000–6000 seeders being present at alltimes.

The change in numbers of seeders over time show that they arenot persistent, and we analyzed the lifetime of seeders by notingthe interval over which their IP address was retrieved over theDHT: this is plotted in Figure 12. The seeder lifetime plot showsa few interesting features. First, the nearly vertical line after onehour corresponds directly to the 72 minute interval over which wereceived new data. The data to the left of the vertical line corre-sponds to the data collected during startup, when our queries werenot rate-limited allowing us to confirm lifetimes shorter than 72minutes. The 72-minute interval accounts for fully 80% of the nodes(i.e., after startup, we saw these nodes only once in our logs.) Seederlifetime is nearly linear beyond the hour, with 10% of the nodespersisting over 10 hours. No seeder in our data persisted beyondone day: 7 out of 42, 794 showed a lifetime of 86, 392 seconds (eightseconds less than one day). This leads us to believe that a bot isnominated to be a seeder for at most one day.

9

Anonymous submission #884 to ACM CCS 2017

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0.0001 0.001 0.01 0.1 1 10 100

Fre

qu

en

cy

Lifetime (Hours)

Figure 12: Lifetime of nodes that seed config files.

6.2 Leecher activityWe now turn to the leechers: the bots that download the configura-tion files.

0

500

1000

1500

2000

2500

3000

May 16 May 17 May 18 May 19

Co

nn

ec

tio

n C

ou

nt

Requests for May 15May 16May 17May 18May 19

Figure 13: Leecher download requests separated by configfile date.

Kademlia allows DHT clients to “announce” named content.Peers seeking the named content search for the name; if the namehad been announced, the DHT search returns a list of announcingpeers. The actual data transfer is conducted outside the DHT itselfusing the µtp protocol.

During May 15, 2017 (2300 hours UTC) until May 19, 2017 (0100hours UTC), we ran twelve BitTorrent DHT peers. They were co-located with our seeder-searcher nodes, but we ran one extra in-stance each in Frankfurt and Northern Virginia. These peers an-nounced the availability of 200 Hajime config files, starting fromNov. 1, 2016. We assigned a different download port for each configfile, enabling us to track requests for individual files. Over the 74hours when we gathered data, we received 1.12 million requestsfor config file downloads from 51,039 unique IP addresses.

The bots requested files for 115 different days, though 1.05 mil-lion (93.7%) of the requests were for files for five days starting May15, 2017. Figure 13 shows requests over time for these five files.Prior analysis had suggested that Hajime bots download a configfile every ten minutes [7]. Our data shows much burstier behavior,with large activity peaks around midnight UTC. Most downloadrequests for a given config file corresponds cleanly with the date;however, for each file, there are two peaks: one around midnightof the file’s date in UTC, and the second around midnight the nextday. Note that our data shows a much smaller second request spike

for May 16th, but the other days with high traffic volume (15th,17–19th) follow the trend of two request peaks.

6.3 Correlating DNS and DHT dataFinally, we present a correlation comparison of our passive data,and the data collected by actively participating in the DHT. Fig-ure 14 shows how the bots identified using the DNS data relate toseeders and leechers in the BitTorrent DHT. The figure counts allbot IP addresses that we had identified in our DNS data (startingDecember 2016): these addresses are intersected with the seederand leecher data collected over three days in May. (We also ana-lyzed data from all three sources over a twelve hour period. Thenumber of leechers and passive nodes reduced by a factor of 3, butthe number of seeders only reduced by a third. The intersectionsreduced proportionately.) The intersection data shows the validityand utility of both approaches, as they both locate bots not foundby the other. The passive DNS approach finds many more bots,partly because any bot that tries to infect another causes it to belogged depending on whether the attempt is successful (and, in ourcase, the probability that the DNS query is routed to the root wemonitor and is sampled by our data collection.) Aggressive effortsto propagate the worm causes the probability of detection to risecommensurately, and whether the DNS query is issued or not is notin control of the bot (author), as this is a pre-programmed reactionfrom the victim. Searching the DHT for the config file seeders isalso an effective way to find bot addresses—about 30% of the seederswere also seen to launch active attacks that were logged by theDNS data. Hosting configuration files and inviting downloads isa seemingly less effective way to find bots, undoubtedly becausethere are many thousands of seeders, which reduces the probabilitythat a particular bot will visit a specific seeder (or seeder-honeypot).

Seeders

Attackers from

Passive DNS

Leechers

66,400

31,573

14,516

15,333

2,098

9,9453,595

Figure 14: Hajime Bots in the DHT and in the DNS data.

7 DISCUSSIONIn relying on a peer-to-peer substrate for command and control,Hajime represents an evolution in the design of botnets. Relying onthe DHT enables a further level of indirection that further obfus-cates the command and control structure; however, the very same

10

Anonymous submission #884 to ACM CCS 2017

design choice also exposes Hajime to generic attacks that DHTs arevulnerable to. In the rest of this section, we discuss a few of theseattacks, along with a weaknesses that are specific to Hajime.

Decentralized DHTs are vulnerable to Sybil attacks [4], wherebymalicious nodes join the DHTmultiple times as different peers, witha view to “taking over” part of the namespace. In general, nodes arehashed to points in the DHT namespace uniformly at random usinga cryptographically strong hash function, and it is not usually noteasy to join a DHT at a specific point in the namespace. However,a sufficiently determined attacker could possibly hijack parts ofthe namespace that host the configuration file, thus stopping botsfrom obtaining files on a given day. Since the filename changesdaily, this attack would have to be sustained in order to be effective.Encrypting or obfuscating the filename is not a particularly viablesolution, since the seeders have to be looked up by DHT nodes,which is not controlled by Hajime. Finally, note that the attackerdoes not have to specifically host the key that corresponds to theconfiguration file: the attacker can be effective if it can generate“nearby” keys that are on the lookup path. The attacker wouldsimply discard lookups for the configuration file key—this type ofattack is called an “insertion” attack, whereby the attacker insertsthemselves on the lookup path, and has been shown to be effectiveagainst Kademlia DHTs in the wild [11].

A somewhatmore blunt approach is to simply look up the currentset of seeders, and then disable them, perhaps by mounting a Denialof Service or an Eclipse attack [11]. Our combined seeder-leecherdata points out an interesting contradiction. The number of seedersis at a minimum when the number of configuration file requestspeak. It is currently unclear whether this behavior is by design(seeders are allowed to voluntarily stop seeding after they haveuploaded a sufficient number of bytes, perhaps to evade detection),or whether it is a result of a yet unforeseen interaction. Our datastrongly suggests that bots seed for at most one day (none of our42K+ seeders lasted more than one day). If there is also a bandwidthlimitation along with a time limit, then an easy way to reduce theseeder set is to simply repeatedly download the configuration file.

Hajime is also vulnerable to attacks specific to its code baseand choice of DHT. There are previously published attacks onKademlia [11, 15], which show that a single attacker with 100 Mbpsof bandwidth can disrupt 75% of all lookups on a Kademlia DHT.Other attacks, such as the publish attack [11], can be both verysuccessful against Hajime and easily mounted. The publish attacknotes that a node holding a key (for the configuration file, in ourcase) returns, at most, the latest 300 announcements it receives forthat key. An attacker could simply flood the network with fake“publish” messages, and thus disrupt the seeder-location process.

8 CONCLUSIONHajime is a new, large IoT botnet that is distinguished by its use ofa existing DHT for command-and-control. In this paper, we haveanalyzed the spread and operation of Hajime using two differentmethods. Our first method employs “DNS backscatter”: we observethat a specific form of unsuccessful Hajime attacks (that exploit theso-called TR-064 vulnerability) can result in a DNS query for aninvalid top-level domain. This query cannot be resolved by anyregular DNS resolver, and is routed to the DNS roots. Using packet

captures from a DNS root server, we uncover millions of bots andattacks since Hajime’s use of TR-064. Our unique vantage pointenables us to track the spread of the bot globally, and gain insightinto its macroscopic behavior at a scale that is not easily replicableusing existing methods such as honeypots.

Simultaneously, we present a second set of experiments thatfocus on Hajime’s use of the DHT. We identify Hajime bots on theDHT using two methods, and provide a detailed analysis of theirlifetime and command and control behavior. Finally, we present ananalysis of vulnerabilities in Hajime itself due to its reliance on aDHT. Our two measurement methods complement, enabling botha global view of the bot’s spread, and a closer view of individualbot’s lifetime and behavior.

REFERENCES[1] Radware ERT Threat Advisory. 2016. Hajime – Friend or foe? Online:

https://security.radware.com/ddos-threats-attacks/hajime-iot-botnet/. (2016).

[2] Akamai. 2016. Akamai’s State of the Internet / Security, Q3 2016 Report. Online:https://www.akamai.com/us/en/multimedia/documents/state-of-the-internet/q3-2016-state-of-the-internet-security-report.pdf. (2016).

[3] Simurgh Aryan, Homa Aryan, and J Alex Halderman. 2013. Internet Censorshipin Iran: A First Look.. In Proceedings of the 3rd USENIX Workshop on Free andOpen Communications on the Internet.

[4] John R. Douceur. 2002. The Sybil Attack. In First International Workshop onPeer-to-Peer Systems (IPTPS ’01).

[5] DSLHome-Technical Working Group. 2004. DSL Forum TR-064: LAN-Side DSLCPE Configuration. Online:https://www.broadband-forum.org/technical/download/TR-064.pdf.(2004).

[6] Dyn. 2016. Dyn Analysis Summary of Friday October 21 Attack. Online:https://dyn.com/blog/dyn-analysis-summary-of-friday-october-21-attack/.(2016).

[7] Sam Edwards and Ioannis Profetis. 2016. Hajime: Analysis of a decentralizedinternet worm for IoT devices. Online:https://security.rapiditynetworks.com/publications/2016-10-16/hajime.pdf. (2016).

[8] Dan Goodin. 2016. BrickerBot, the permanent denial-of-service botnet, is backwith a vengeance. Online:https://arstechnica.com/security/2017/04/brickerbot-the-permanent-denial-of-service-botnet-is-back-with-a-vengeance/.(2016).

[9] Waylon Grange. 2016. Hajime worm battles Mirai for control of the Internet ofThings. Online:https://www.symantec.com/connect/blogs/hajime-worm-battles-mirai-control-internet-things. (2016).

[10] Krishna P. Gummadi, Stefan Saroiu, and Steven D. Gribble. 2002. King: EstimatingLatency between Arbitrary Internet End Hosts. In ACM Internet MeasurementWorkshop (IMW).

[11] Thomas Locher, David Mysicka, Stefan Schmid, and Roger Wattenhofer. 2010.Poisoning the Kad Network. In 11th International Conference on DistributedComputing and Networking (ICDCN).

[12] Ramakrishna Padmanabhan, Amogh Dhamdhere, Emile Aben, kc claffy, and NeilSpring. 2016. Reasons Dynamic Addresses Change. In ACM Internet MeasurementConference (IMC).

[13] Stuart Staniford, Vern Paxson, and Nicholas Weaver. 2002. How to 0wn theInternet in Your Spare Time. In USENIX Security Symposium.

[14] Brett Stone-Gross, Marco Cova, Lorenzo Cavallaro, Bob Gilbert, Martin Szyd-lowski, Richard Kemmerer, Christopher Kruegel, and Giovanni Vigna. 2009. YourBotnet is My Botnet: Analysis of a Botnet Takeover. In ACM Conference onComputer and Communications Security (CCS).

[15] Peng Wang, James Tyra, Eric Chan-Tin, Tyson Malchow, Denis Foo Kune,Nicholas Hopper, and Yongdae Kim. 2008. Attacking the Kad Network. In Proceed-ings of the 4th International Conference on Security and Privacy in CommunicationNetowrks (SecureComm ’08).

11