characterization and analysis of ntp amplifier...

11
Vol.107 (2) June 2016 SOUTH AFRICAN INSTITUTE OF ELECTRICAL ENGINEERS 54 CHARACTERIZATION AND ANALYSIS OF NTP AMPLIFIER TRAFFIC L. Rudman * and B. Irwin * Security and Networks Research Group, Dept. of Computer Science, Rhodes University, Grahamstown 6139, South Africa E-mail: [email protected] Security and Networks Research Group, Dept. of Computer Science, Rhodes University, Grahamstown 6139, South Africa E-mail: [email protected] Abstract: Network Time Protocol based DDoS attacks saw a lot of popularity throughout 2014. This paper shows the characterization and analysis of two large datasets containing packets from NTP based DDoS attacks captured in South Africa. Using a series of Python based tools, the dataset is analysed according to specific parts of the packet headers. These include the source IP address and Time-to-Live (TTL) values. The analysis found the top source addresses and looked at the TTL values observed for each address. These TTL values can be used to calculate the probable operating system or DDoS attack tool used by an attacker. We found that each TTL value seen for an address can indicate the number of hosts attacking the address or indicate minor routing changes. The Time-to-Live values are then analysed as a whole to find the total number used throughout each attack. The most frequent TTL values are then found and show that the majority of them indicate the attackers are using an initial TTL of 255. This value can indicate the use of a certain DDoS tool that creates packets with that exact initial TTL. The TTL values are then put into groups that can show the number of IP addresses a group of hosts are targeting. The paper discusses our work with two brief case studies correlating observed data to real-world attacks, and the observable impact thereof. Key words: denial of service, network security, network time protocol. 1. INTRODUCTION Distributed Reflection Denial of Service (DRDoS) attacks using Network Time Protocol (NTP) servers gained popularity in late 2013 and continued to be a factor in a number of major attacks in the first half of 2014 [1]. The Network Time Protocol is used to distribute accurate time information to networked computers [2]. There are many public NTP servers throughout the Internet that are used by legitimate client systems in order to synchronize system clocks. A NTP server which is exploitable in this type of attack allows the use of the MONLIST command. This command returns up to the last 600 client IP addresses that have queried an NTP server, and has traditionally been used as part of the NTP protocol suite operational debugging [3]. Vulnerable NTP servers can thus provide a high degree of amplification scale as the MONLIST request packet is significantly smaller than the reply packet(s) generated. The MONLIST request UDP packet size is around 64 bytes and the reply ”can be magnified to 100 responses of 482 bytes each [4], thus providing a potentially large amplification bot in terms of bytes (Byte Amplification Factor - BAF) and packets ( Packet Amplification Factor - PAF). Combined with the ease of spoofing the source of UDP traffic, this amplification, makes NTP servers an ideal resource for DDoS attacks [5]. As seen in Figure 1, the attack is carried out by sending NTP MONLIST requests with a spoofed source address of the intended target of the attack to a vulnerable NTP server on port 123/udp [6]. The server then sends the replies to the spoofed IP address (the victim) which is then flooded with large volumes of traffic. This in turn can have further impact on systems beyond just bandwidth exhaustion as receivers need to process datagrams which are not necessarily of the correct protocol, depending on the spoofed source port used. Figure 1: Distributed Denial of Service attack using NTP servers as reflectors In [6], it was stated that from January to February of 2014, the number of NTP amplification attacks had increased considerably with one of these attacks reaching just below 400 Gbps. It was reported as being the largest attack recorded using NTP. In early 2014 there were more than 430 000 vulnerable NTP servers [7]. By April 2014, Arbor Networks released data that showed that 85% of DDoS attacks above 100 Gbps were using NTP amplification [7]. However by June 2014, this number decreased to around 17 647 vulnerable servers largely due to the application of patches and configuration changes by network administrators [4]. A report released by Arbor Networks in October 2014 showed that NTP amplification based attacks are decreasing, with a little over 50% of incidents in excess of 100 Gbps using this protocol [8]. The problem with this class of attacks is that the real address of an attacker is never used due to the spoofing of Based on: “Characterization and Analysis of NTP Amplification Based DDoS Attacks”, by L. Rudman and B. Irwin which appeared in the Proceedings of Information Security South African (ISSA) 2015, Johannesburg, 12 & 13 August 2015. © 2015 IEEE

Upload: others

Post on 18-Mar-2020

0 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: CHARACTERIZATION AND ANALYSIS OF NTP AMPLIFIER TRAFFICaz817975.vo.msecnd.net/wm-418498-cmsimages/ARJJune2016-6-161.pdf · 54 S IN INSI I NINS V107 2 2016 CHARACTERIZATION AND ANALYSIS

Vol.107 (2) June 2016SOUTH AFRICAN INSTITUTE OF ELECTRICAL ENGINEERS54

CHARACTERIZATION AND ANALYSIS OF NTP AMPLIFIERTRAFFIC

L. Rudman∗ and B. Irwin†

∗ Security and Networks Research Group, Dept. of Computer Science, Rhodes University,Grahamstown 6139, South Africa E-mail: [email protected]† Security and Networks Research Group, Dept. of Computer Science, Rhodes University,Grahamstown 6139, South Africa E-mail: [email protected]

Abstract: Network Time Protocol based DDoS attacks saw a lot of popularity throughout 2014. Thispaper shows the characterization and analysis of two large datasets containing packets from NTP basedDDoS attacks captured in South Africa. Using a series of Python based tools, the dataset is analysedaccording to specific parts of the packet headers. These include the source IP address and Time-to-Live(TTL) values. The analysis found the top source addresses and looked at the TTL values observedfor each address. These TTL values can be used to calculate the probable operating system or DDoSattack tool used by an attacker. We found that each TTL value seen for an address can indicate thenumber of hosts attacking the address or indicate minor routing changes. The Time-to-Live values arethen analysed as a whole to find the total number used throughout each attack. The most frequent TTLvalues are then found and show that the majority of them indicate the attackers are using an initial TTLof 255. This value can indicate the use of a certain DDoS tool that creates packets with that exact initialTTL. The TTL values are then put into groups that can show the number of IP addresses a group ofhosts are targeting. The paper discusses our work with two brief case studies correlating observed datato real-world attacks, and the observable impact thereof.

Key words: denial of service, network security, network time protocol.

1. INTRODUCTION

Distributed Reflection Denial of Service (DRDoS) attacksusing Network Time Protocol (NTP) servers gainedpopularity in late 2013 and continued to be a factor ina number of major attacks in the first half of 2014 [1].The Network Time Protocol is used to distribute accuratetime information to networked computers [2]. There aremany public NTP servers throughout the Internet that areused by legitimate client systems in order to synchronizesystem clocks. A NTP server which is exploitable inthis type of attack allows the use of the MONLISTcommand. This command returns up to the last 600 clientIP addresses that have queried an NTP server, and hastraditionally been used as part of the NTP protocol suiteoperational debugging [3]. Vulnerable NTP servers canthus provide a high degree of amplification scale as theMONLIST request packet is significantly smaller than thereply packet(s) generated. The MONLIST request UDPpacket size is around 64 bytes and the reply ”can bemagnified to 100 responses of 482 bytes each [4], thusproviding a potentially large amplification bot in termsof bytes (Byte Amplification Factor - BAF) and packets( Packet Amplification Factor - PAF).

Combined with the ease of spoofing the source of UDPtraffic, this amplification, makes NTP servers an idealresource for DDoS attacks [5]. As seen in Figure 1, theattack is carried out by sending NTP MONLIST requestswith a spoofed source address of the intended target ofthe attack to a vulnerable NTP server on port 123/udp [6].The server then sends the replies to the spoofed IP address(the victim) which is then flooded with large volumes of

traffic. This in turn can have further impact on systemsbeyond just bandwidth exhaustion as receivers need toprocess datagrams which are not necessarily of the correctprotocol, depending on the spoofed source port used.

Figure 1: Distributed Denial of Service attack using NTP serversas reflectors

In [6], it was stated that from January to February of 2014,the number of NTP amplification attacks had increasedconsiderably with one of these attacks reaching just below400 Gbps. It was reported as being the largest attackrecorded using NTP. In early 2014 there were morethan 430 000 vulnerable NTP servers [7]. By April2014, Arbor Networks released data that showed that85% of DDoS attacks above 100 Gbps were using NTPamplification [7]. However by June 2014, this numberdecreased to around 17 647 vulnerable servers largely dueto the application of patches and configuration changes bynetwork administrators [4]. A report released by ArborNetworks in October 2014 showed that NTP amplificationbased attacks are decreasing, with a little over 50% ofincidents in excess of 100 Gbps using this protocol [8].

The problem with this class of attacks is that the realaddress of an attacker is never used due to the spoofing of

Based on: “Characterization and Analysis of NTP Amplification Based DDoS Attacks”, by L. Rudman and B. Irwin which appeared in the Proceedings of Information Security South African (ISSA) 2015, Johannesburg, 12 & 13 August 2015. © 2015 IEEE

Page 2: CHARACTERIZATION AND ANALYSIS OF NTP AMPLIFIER TRAFFICaz817975.vo.msecnd.net/wm-418498-cmsimages/ARJJune2016-6-161.pdf · 54 S IN INSI I NINS V107 2 2016 CHARACTERIZATION AND ANALYSIS

Vol.107 (2) June 2016 SOUTH AFRICAN INSTITUTE OF ELECTRICAL ENGINEERS 55

the source IP address [9]. More detailed analysis of suchattacks is therefore important in order to gain informationwhich may be valuable in mitigating or finding the sourceof an attack. In this paper a number of characteristics of theattacks are looked at. The primary focus, however, relatesto the observed TTL values within the IP header. Theanalysis of these has shown that they can be used to provideinsight on how many hosts are being used to generaterequest packets or where they may be in the world.

The remainder of this paper is structured as follows.Section 2 looks at related research in the area of Denialof Service and NTP based Denial of Service attacks inparticular. The data sources used and analysis processundertaken are described in Section 3. Results of theanalysis of the two datasets are presented in Sections 4 and5 respectively. Two brief case studies arising out of theanalysis of the combined data are presented in Section 6.The paper concludes with Section 7, which also considerspossible future work.

2. RELATED WORK

Czyz et al. [10], reported on their analysis of NTPDDoS attacks which were were analyzed on a globalscale. This was achieved by looking at the rise ofNTP amplification attacks, how many amplifiers therewere, and their amplification scale. The victims of theattacks were found by looking at the source port of theoriginal attack packets. It was found that most targetswere related to online gaming, with victims includingMinecraft, Runescape and Microsoft Xbox live service.The most popular source port was port 80/udp which, asthey stated, may have been used to target games that usethis port or websites. When classifying the number ofattacks that occurred throughout a 15-week period, whilemonitoring a number of amplifiers, a simplification wasused by classifying each unique targeted IP in a week-longsample as one attack. This simplification does not takeinto account attacks targeting network blocks or a singleIP hosting multiple sites.

In relation to TTL analysis it was determined by[10] that most of the attack traffic from a ColoradoState University dataset appeared to originate fromWindows-based machines and that they are probablycomputers in a botnet. This is because the mode of the IPv4TTL field was observed to be 109, and the default initialTTL set on Microsoft Windows platforms is 128. Whatthese researchers failed to mention was that the attackerscould have been using a DDoS tool that could have set theinitial TTL to 128 or slightly above.

3. RESEARCH

At the time of the research being conducted in early2014, there had not been much in-depth research intothe interplay of TTL values and NTP DDoS. The driverbehind this research was to investigate a number of packetcharacteristics relating to the observed TTL values ofrecorded inbound traffic. In addition, the source IP

address, source port, UDP header size and IP datagram sizewere also analyzed. The purpose of this was to determinethe victims of the attacks in a similar manner to that usedin [10].

3.1 Data Sources

The analysis carried out and presented in the remainderof this paper was based on two packet captures obtainedfrom systems running a vulnerable version of the NTPsoftware (NTP 4.2.6 or below). Packet captures wererecorded using tcpdump. Packets that did not contain asource or destination port of 123/udp were filtered outprior to analysis as they did not contain a MONLISTrequest or reply and would not have contacted a vulnerableNTP server for potential amplification. Both datasetswere collected within South African IPv4 address space,contained within AS2018 (TENET). An overview of thelogical capture setup is shown in Figure 2.

Figure 2: Capture points of the two datasets

ZA1: The ZA1 data set consists of data collected between15 July 2013 and 9 March 2014. The capture files havea combined size of 3.2 GB and contain a total of 32 799299 packets. The captures show two attacks lasting aroundtwo weeks each. These were observed in the periods 23December 2013 to 7 January 2014 and 10-25 February2014 respectively. This dataset is of interest as the datacapture was initiated pre-exploitation, and contains trafficdestined for a single IP address.

ZA2: The capture files constituting the ZA2 dataset

Page 3: CHARACTERIZATION AND ANALYSIS OF NTP AMPLIFIER TRAFFICaz817975.vo.msecnd.net/wm-418498-cmsimages/ARJJune2016-6-161.pdf · 54 S IN INSI I NINS V107 2 2016 CHARACTERIZATION AND ANALYSIS

Vol.107 (2) June 2016SOUTH AFRICAN INSTITUTE OF ELECTRICAL ENGINEERS56

consisted of 103 060 564 packets in total amounting to11.5 GB, which were captured over a period of just overone month, from 12 February 2014 to 10 March 2014.This data was captured after the initially detected attackhad been mitigated. It contains both request and replyMONLIST packets and sees a larger number of packetsper hour compared to ZA1. This is partially due to the factthat it was collected by recording traffic for the majority oftarget IP addresses within a single /27 IPv4 net block. Forthe purposes of this paper, the analysis across addresseshas been merged, and individual activity has not beenanalysed.

3.2 Analysis Tools

Analysis was performed using a series of customdeveloped tools which were implemented in Python. Thistoolchain was used to parse and extract data from the rawpacket captures, and then filter and plot time series graphsof information such as packets per hour, unique hosts perhour, IP addresses with a certain TTL, TTL per hour, IPdatagram length, UDP datagram length, TTL frequencyand others. The tools also outputted .csv files of the rankedsource data which was be used for processing and analysisof the data in other tools.

3.3 Address Disclosure

The IP addresses reported in this research are thoseobserved as source addressed of the datagrams attemptingto exploit NTP systems within the two monitorednetworks. In the vast majority of cases these can reliablybe determined to be the spoofed addresses of the attackersintended targets. These addresses have not been blindedor obscured, as the attacks against these organisationshave have been well publicized and documented. Currentaddressing information can be trivially obtained usingcommon search tools and DNS resolution. IT is felt thatthe disclosure fo the addresses may help other researchersin future efforts around correlation of data relating tovictims of such attacks.

4. ZA1 ANALYSIS

This section presents the results of the analysis conductedon the ZA1 dataset. Two periods of exploitation wereduring the observed period were determined to be 23December 2013 to 7 January 2014 and 10-25 February2014. These can be seen clearly in Figure 3. Peak packetrates in excess of 500 000 packets/hour were observed inthe initial attack. Packet rates subsequently decreased toaround 50 000 packets/hour for the remainder of the attack.Significant diurnal trends were observed in the secondphase. These patterns can be similarly observed in Figure4 which plots the number of unique source hosts observedduring each hour period. For both attacks the unique hostsstarted off with a considerably higher value than the restof the unique host values of the attack. This is possiblydue to attackers priming the NTP servers (by floodingwith generated queries from different source addresses),

Table 1: Top 10 IP addresses from ZA1Rank IP address Count % TTL

1 217.168.137.25 3 896 074 11.8846 (9.21%)47 (1.85%)50 (88.54%)

2 72.46.150.210 320 816 0.983 64.37.171.32 257 066 0.78 1114 85.17.207.236 253 588 0.77 1115 159.153.228.77 228 753 0.7 1116 62.67.0.130 204 174 0.62 1117 192.95.11.54 189 224 0.58 111

8 63.251.20.99 163 830 0.5111 (98.73%)232 (0.25%)234 (1.20%)

9 212.143.95.26 154 368 0.47 11110 75.126.29.106 150 659 0.46 111

Total 5 818 552 % 17.74%

in order to get the maximum amplification scale for theattack using the NTP MONLIST command, there musthave been over 600 historical connections to the serverwhich can then be sent in response to the forged packet.The remainder of the section considers specific attributesof the observed attack traffic.

Figure 3: Packets per hour for ZA1

Figure 4: Unique hosts per hour

4.1 Source IP and TTL

An analysis of the observed source addresses shows that asingle address (217.168.137.25) was observed at a level inexcess of an order of magnitude more than the other topsources with its packets taking up 11% of the total packetsobserved. This target address is located in Poland, and wasmost likely hosting online gaming services. However atthe time of the analysis, the system had been taken offline,and as such is it is not possible to confirm this. Table1 lists the traffic for the top 10 observed sources, which

Page 4: CHARACTERIZATION AND ANALYSIS OF NTP AMPLIFIER TRAFFICaz817975.vo.msecnd.net/wm-418498-cmsimages/ARJJune2016-6-161.pdf · 54 S IN INSI I NINS V107 2 2016 CHARACTERIZATION AND ANALYSIS

Vol.107 (2) June 2016 SOUTH AFRICAN INSTITUTE OF ELECTRICAL ENGINEERS 57

Table 2: Top 10 TTL values for ZA1

Rank TTL Packet Count % of totalInitialTTL

1 111 25 771 844 78.57 1282 50 3 575 563 10.9 60 or 643 236 920 462 2.81 2554 234 864 950 2.64 2555 232 434 480 1.32 2556 46 359 082 1.09 60 or 647 237 111 038 0.34 2558 242 82 377 0.25 2559 62 78 255 0.24 60 or 64

10 47 71 969 0.22 60 or 64Total 32 270 020 % of total 98.39%

constitute 17.74% of the overall traffic. This indicatesthat the IP address was targeted from the beginning ofthe attack, and the varying TTL values observed furthershow a strong likelihood that more than one host was beingused to spoof packets with this source address. The TTLvalues found in packets using the top IP address couldindicate three different attacking hosts or one host withrerouted packets. As shown in the Table 1, there are onlytwo IP addresses where more than a single TTL valuewas observed. This is indicative of multiple participantsspoofing the address, or minor routing changes havingoccurred during the attack. Further investigation into thetemporal overlap is discussed in future work. Taking a lookat the IP address 63.251.20.99, it can be seen that thereis a distinct difference between the observed TTL values.Although the majority of the packets have a TTL of 111 (incommon with the majority of traffic) there are some with avery high TTL value. The occurrences of the top 10 TTLs,are shown in Table 2.

4.2 Time-to-Live values

There were a total of 64 distinct TTL values observed. Themost frequent of these being 111, which could mean theattacker was using a Windows operating system (assumingthe TTL is not spoofed) as Windows sets the initial TTLto 128. This is a similar result to [10] and may indicate abotnet being used or one host attacking multiple victims.

4.3 TTL Groups

Based on the top 10 TTL values shown in Table 2, the IPaddresses for which two or more TTLs were observed wereisolated. This resulted in 4 679 IP addresses out of the 56273 IP source addresses being observed with multiple TTLvalues, which comprises of just over 8%. The isolated IPaddresses and their observed TTLs were analysed to findwhich IP addresses used the same group of TTL values.The top 10 groupings of TTLs are shown in Table 3.

There were 51 different groups of TTLs found. The mostfrequent being the TTL values of 234 and 236 with 3 207IP addresses observed. Although not shown in Table 3,

Table 3: Top 10 TTL ranges in ZA1Rank TTL group Unique IP % of total

1 234, 36 3207 68.542 232, 236 245 5.243 111, 236 232 4.964 232, 234, 236 201 4.35 111, 234 116 3.556 111, 234, 236 97 2.077 232, 234 72 1.548 234, 236, 237 72 1.549 236, 237 54 1.1510 62, 111 45 0.96

Total 4341 % of total 92.78%

the largest group included six out of the top 10 TTLs (62,111, 232, 234, 236, 237). This was however observedwith only four IP addresses. The number of distinct TTLvalues observed within a group (all claiming to be from asingle IP source address) is strongly indicative of multiplehosts being involved in generating the attack traffic. Whilethe data shows that multiple hosts are likely involved itis difficult to determine with any certainty as to the exactnumber given the vagaries of Internet routing.

As such, the first ranked TTL group in Table 3 couldindicate that two hosts were possibly attacking 3 207different IP addresses (the spoofed source address beingthat of the target of the amplification attack). It could alsoindicate that the hosts attacking the 3 207 IP addresseswere using a DDoS tool that set the default TTL to 255,which means there could be more than two attacking hosts.By extension given similar routing topologies there couldbe two groups of hosts generating the spoofed traffic.

4.4 Full packet size

The packet sizes were analysed because there are a smallnumber of NTP DDoS tools and there are two sizes ofpacket sizes generated by them, so this may be useful indetermining a probable tool and learning more about anattacker.

The ZA1 dataset contained five distinct packet lengths,shown in the x-axis of Figure 5. The most frequentlength being 60 bytes, which according to [11] [12], couldindicate that the attacker was using a Perl based DDoS∗ ora Python based tool named ntpdos.py∗∗. The Perl tool isthe only DDoS tool out of the previously mentioned three,to explicitly set its TTL value to 255 (instead of relyingon the OS default). We can therefore assume with a fairlyhigh degree of certainty that the 60 bytes packets, whoseTTLs were above 230, were generated from this tool. Theobserved packet payloads for this traffic also match the Perltool.

The next most frequent packet length observed is 234

∗ http://goo.gl/MpDU97 https://goo.gl/QzLnXC∗∗ https://goo.gl/9qAauN

Page 5: CHARACTERIZATION AND ANALYSIS OF NTP AMPLIFIER TRAFFICaz817975.vo.msecnd.net/wm-418498-cmsimages/ARJJune2016-6-161.pdf · 54 S IN INSI I NINS V107 2 2016 CHARACTERIZATION AND ANALYSIS

Vol.107 (2) June 2016SOUTH AFRICAN INSTITUTE OF ELECTRICAL ENGINEERS58

bytes, which according to [13] can be generated by aPython program called ntp MONLIST.py∗∗∗ or with theuse of a special query program which is part of the NTPsoftware suite – ntpdc† . This program can be usedto create a MONLIST request of 234 bytes accordingto [11] [12]. This program’s MONLIST command andthe resulting query datagram can be used in a script thatgenerates large number of the requests, as has been donewith the Python script which just encapsulated the queryas generated by ntpdc. As shown in Figure 5, the packetsthat have a length of 234 bytes also have TTL values of46, 47 and 50 (the other four values can be ignored as theirobserved packet count is below ten and this can be regardedas anomalous).

When a MONLIST request is sent to a server, that has afull list of hosts that have connected to it, the reply packetsare 482 bytes each [14].

Figure 5: Full packet length per TTL value for ZA1

5. ZA2 ANALYSIS

Figure 6: Packets per hour for ZA2

Figure 7: Unique hosts per hour for ZA2

This section presents results of the analysis conducted onthe ZA2 dataset. The dataset, which spans a shorter overall

∗∗∗https://goo.gl/SufSrS† http://doc.ntp.org/4.1.2/ntpdc.htm

time period than the ZA1 set, contains nearly three timesthe volume of traffic, and shows sustained attack trafficover the period. As noted in Section 3.1, this merges attacktraffic across a number of hosts within a /27 net block.The volume of the observed traffic is shown in Figure6; however this lacks the clear break in attacks as seenpreviously in Figure 3. This attack saw a peak packet perhour rate of around 2 million, which is significantly largerthan the peak rate of ZA1 (although it is acknowledgedthat there are a larger number of targets in this sample).Figure 7 shows a similar diurnal pattern as seen in Figure4. Another similarity between the two unique source hostsper hour plots is the considerably high packet count at thestart of the capture.

5.1 Source IP and TTL

As shown in Table 4, which lists the traffic for the top 10observed sources, as was found in the ZA1 analysis, thereis one IP address (217.168.137.25) that is observed at alevel in excess of an order of magnitude more than theother top sources. This address was also observed with ahigh count on other or monitored NTP servers around theworld around during the same time period [4] [15] [16].The TTL values observed for packets originating from217.168.137.25 were 47, 51 and 48, which are similar TTLvalues for this IP address in ZA1. This is indicative ofmultiple participants spoofing the address, minor routingoccurring during the attack or the attackers used a similarDDoS tool. Most importantly, it shows the exploitation ofmultiple servers used as reflectors in amplification attacksagainst targets since the same source IPs were observed inboth datasets.

Unlike the ZA1 dataset where only two of the top 10 sourceaddresses were observed with more than one TTL, the ZA2dataset shows all top 10 source addresses having trafficwith at least two, and in most cases, more than five distinctTTL values. This strongly supports the supposition thatmore than one attack source was used to generate attacktraffic to be reflected and amplified towards the intendedvictim. In addition the exploited NTP servers were used inthe attack of multiple target hosts.

5.2 Time-to-Live values

A total of 248 distinct TTL values were observed. Themost frequent being 236, which could mean the attackerwas using a tool that sets the initial TTL to the maximum of255, rather than relying on the operating system defaults.Table 5 shows the top 10 TTLs observed in the ZA2dataset. Eight of the top 10 TTLs are < 230, whichsuggests the initial TTL was set to 255. The Perl NTPDDoS tool mentioned in Section 4.4 could have been usedhere. The TTL of 64, seen in Table 5, is the initial TTL ofthe NTP servers. This TTL signifies all the traffic that hasbeen reflected by the servers.

Page 6: CHARACTERIZATION AND ANALYSIS OF NTP AMPLIFIER TRAFFICaz817975.vo.msecnd.net/wm-418498-cmsimages/ARJJune2016-6-161.pdf · 54 S IN INSI I NINS V107 2 2016 CHARACTERIZATION AND ANALYSIS

Vol.107 (2) June 2016 SOUTH AFRICAN INSTITUTE OF ELECTRICAL ENGINEERS 59

Table 4: Top 10 IP addresses from ZA2

Rank IP address Count

%ofto-tal

TTL

1 217.168.137.25 18 565 847 18.01 47 (9.67%)51 (87.98%)

2 162.218.54.28 3 158 997 3.07

232 (6.18%)233 (7.93%)234 (69.82%)235 (2.29%)236 (7.37%)238 (6.41%)

3 192.64.169.29 2 322 018 2.25

234 (8.26%)235 (9.02%)236 (73.58%)237 (0.87%)243 (0.41%)

4 178.32.140.23 1 820 792 1.77

233 (0.37%)235 (9.60%)236 (66.99%)237 (4.25%)238 (14.65%)243 (0.84%)

5 198.50.180.205 1 495 278 1.45

232 (31.15%)233(11.37%)235 (2.51%)236 (54.86%)238 (0.10%)

6 37.187.77.125 1 210 377 1.17

235 (77.27%)236 (8.34%)237 (2.95%)238 (11.26%)

7 178.32.137.207 825 674 0.8

232 (0.38%)233 (6.22%)235 (19.09%)236 (65.16%)237 (4.28%)243 (1.43%)

8 94.23.19.43 751 176 0.73

233 (3.31%)235 (35.45%)236 (19.26%)237 (7.38%)243 (23.16%)

9 109.163.224.34 682 706 0.66

236 (57.45%)237 (7.19%)238 (34.68%)64 (0.66%)

10 198.27.74.181 677 972 0.66

236 (43.53%)233 (14.69%)232 (2.36%)234 (19.20)235 (20.22%)

Total 31 510 837

%ofto-tal

30.58%

Table 5: Top 10 TTL values for ZA2Rank TTL Packet Count % of total Initial TTL

1 236 23 509 039 22.81 2552 235 17 009 527 16.5 2553 51 16 778 624 16.28 60 or 644 237 13 946 335 13.53 2555 232 4 054 193 3.93 2556 234 3 893 500 3.78 2557 238 2 755 487 2.67 2558 243 2 451 201 238 2559 64 2 232 754 2.17 100/128?10 233 2 152 300 2.08 255

Total 887 829 60 % of total 86.15%

Table 6: Top 10 TTL ranges in ZA2Rank TTL group Unique IPs % of total

1 235, 237 3 440 38.992 233, 237 244 2.773 233, 235, 237 167 1.894 234, 237 137 1.555 236, 237 131 1.486 234, 235, 237 93 1.057 232, 234 88 1.008 237, 64 88 1.009 235 ,236, 237 69 0.7810 235, 237, 238 60 0.68

Total 4517 % of total 51.20%

5.3 TTL Groups

From the top 10 TTL values seen (shown in Table 5), theIP addresses which used two or more TTLs were found.This resulted in 8 823 IP addresses out of the 38 634 IPaddresses seen. There were 143 different groups of TTLsfound, the top 10 of which are shown in Table 6. Themost frequent being 235 and 237 with 3 440 IP addressesobserved using only these. Although not shown in Table6 the largest group of top 10 TTLs included of nine out ofthe top 10 TTLs (232, 233, 234, 235, 236, 237, 238, 51,64) however, only one (spoofed) IP address was observedto be part of this grouping. This again illustrates the strongevidence towards multiple sources for the spoofed traffic.

5.4 Full packet size

The ZA2 dataset showed similar results to ZA1 andcontained 12 distinct full packet sizes, shown in Figure 8.The most frequent being 60 bytes, which is the same resultas observed in the ZA1 dataset. As previously stated inSection 4.4, this length could indicate the use of a Perl orPython tool. In Figure 8, it is observed that 8 out of 9 ofthe TTL values seen with a full packet size of 60 bytes arearound 230, which is indicative of the use of the Perl tool,because this tool sets the TTL field to 255 and generatespackets of 60 bytes.

Page 7: CHARACTERIZATION AND ANALYSIS OF NTP AMPLIFIER TRAFFICaz817975.vo.msecnd.net/wm-418498-cmsimages/ARJJune2016-6-161.pdf · 54 S IN INSI I NINS V107 2 2016 CHARACTERIZATION AND ANALYSIS

Vol.107 (2) June 2016SOUTH AFRICAN INSTITUTE OF ELECTRICAL ENGINEERS60

As seen in ZA1 and ZA2, and seen in 8, the secondmost frequent packet size is 234 bytes. Packetsobserved with this size were most likely generated by thentp MONLIST.py or ntpdc programs. The most frequentTTL seen in packets of 234 bytes is 51, which is the TTLthat is observed for the top IP address. This is a similarresult to ZA1, where the most frequent TTL seen in the234 byte packets are 46, 47 and 50, which are also theTTLs observed for the top IP address.

Because the ZA2 dataset contains request and reflectedpackets, a packet length of 482 is observed. Packets withthis length are only obseved with a TTL of 64, which is theinitial TTL for ZA2 server. These packets are the reflectedpackets that are generated from the 60 and 234 byte requestpackets. In the case when the MONLIST table was notyet full, the 122, 194, 266, 338, 410 byte packets couldindicate the reply packet sizes as the NTP monitor list grewlonger.

Figure 8: Full packet length per TTL value for ZA2

6. COMMON CHARACTERISTICS

This section briefly discussed the similarities of the twodatasets. The first similarity found was observed in Section4 and 5, between the unique hosts per hour, where therewas a large spike of over 600 unique hosts per hour at thestart of each attack illustrated in Figure 4 and 7. As statedpreviously, this is possibly due to attackers priming theNTP servers, in order to get the maximum amplificationscale from the MONLIST command.

The top IP address seen in ZA1 was also the top IP addressfor ZA2. This fact will be explored further in Section 7.1,where it will be shown that the address is being attacked bythe same attacker. Although not shown in this paper, thetop 20 domain names of the source addresses and the top20 source ports for ZA1 and ZA2 indicate that the majorityof the targets are online gaming related. Out of the top 20source ports, ZA1 and ZA2 had 13 ports in common, withmost of them being common online gaming ports.

Taking a look at the top 10 TTLs listed in Table 2 and Table5 it is observed that ZA1 has 5 TTLs and and ZA2 has8 TTLs whose values are above 230. Together with theinformation from Figure 5 and Figure 8 it was found thatthe attackers that used the ZA1 and ZA2 servers were usingthe Perl DDoS tool.

Table 7: TTL values for 217.168.137.25 in the ZA1dataset

Rank TTL Count %1 50 3 449 705 88.542 46 358 966 9.213 47 71 933 1.854 51 15 395 0.45 54 49 0.00136 48 18 0.00057 49 5 0.00018 45 2 0.009 53 1 0.00

Total: 3 896 074

Table 8: TTL values for 217.168.137.25 in the ZA2dataset

Rank TTL Count %1 51 16 334 079 87.982 47 1 794 768 9.673 48 359 660 1.944 52 76 880 0.415 55 295 0.00156 49 125 0.00077 50 35 0.00028 54 5 0.00

Total: 18 565 847

7. CASE STUDIES

The following section will discuss two case studies.The first being a brief analysis of the top IP address(217.168.137.25) observed in the ZA1 and ZA2 datasetand the similarities of the results found. The second casestudy is about a group who call themselves Derp Trollingand the evidence showing that they may have used thevulnerable server in ZA1 to carry out DDoS attacks ononline gaming related IP addresses.

7.1 Top IP address

The IP address (217.168.137.25) was observed as the topIP address in both the ZA1 and ZA2 datasets. As shownin Tables 7 and 8, the TTL values seen in the ZA1 datasetare one less than the TTLs seen in the ZA2 dataset (anexception being the TTL of 45 in Table 7). This is becausethe ZA1 data capture point was one more hop away asshown in Figure 2. Looking at the percentages of eachof the TTL values in the Tables, it can be seen that thepercentages are extremely similar. This is a factor thatmade it possible that both of the datasets contained packetsfrom the same attacker.

Since there is one dominant TTL value, it strongly supportsthe rerouting of packets. Figure 9 and 10, which showthe packets per hour of the top IP address (separated bycoloured TTL values). Because the ZA1 and ZA2 capturepoints were one hop apart from the attacker, the colours

Page 8: CHARACTERIZATION AND ANALYSIS OF NTP AMPLIFIER TRAFFICaz817975.vo.msecnd.net/wm-418498-cmsimages/ARJJune2016-6-161.pdf · 54 S IN INSI I NINS V107 2 2016 CHARACTERIZATION AND ANALYSIS

Vol.107 (2) June 2016 SOUTH AFRICAN INSTITUTE OF ELECTRICAL ENGINEERS 61

were changed accordingly. This produced two very similargraphs, which show the rerouting of packets during theattack. What must be noted is that although they are thesame shape, the ZA2 dataset has a higher packet countwhich stayed steady around 107 000 packets per hour. Thisis nearly five times as many packets as the ZA1 datasetthat saw a steady 21 400 packets per hour. This differencemay be because of bandwidth changes. Because the ZA2dataset was captured after the attack had started, Figure 10does not show packets from the beginning of the attack, butthey would most likely have the same shape as the start ofFigure 9.

The evidence shown throughout the two dataset analyses,and the above information given in this section leads theauthors to the conclusion that there was one coordinatedgroup of attackers using multiple vulnerable NTP serversfor amplification. A portion of this attack traffic wascaptured by the packer loggers which resulted in the ZA1and ZA2 datasets.

Figure 9: Packets per hour for ZA2

Figure 10: Packets per hour for ZA2

7.2 Derp Trolling

Derp Trolling or Derp for short, is the name of a hackergroup that carried out numerous DDoS attacks from late2013 and throughout 2014 mainly targeting gaming relatedservers [17]. Their twitter account†† is full of tweetsabout their previous attacks. The account however stoppedtweeting about attacks in August 2014, and the hackerclaims to have become a white hat hacker. The next fewparagraphs show the observations that make it likely thatthis hacker group used the ZA1 server as a reflector in theirattacks. The group was found when looking at the domain

†† https://twitter.com/DerpTrolling

names of the top 20 source addresses and noticing thatmany of the domains were game related. After searchingonline for DDoS attacks on DC universe online, all thesearch results pointed at Derp Trolling. These posts fallwithin the times frames of the attack traffic observed inthe ZA1 dataset. While its impossible to prove that theobserved traffic was definitiavely the result of activities bythis group, the precise timing, and choice of targets, have ahigh correlation with their posted activity reports. Afterfinding their twitter page, it was clear that many of theother top 20 source addresses were related to their attacksduring the period of observation.

DC Universe Online: DC Universe Online‡ is a massivelymultiplayer online role-playing game (MMORPG). DerpTrolling may have used the ZA1 server along with othervulnerable NTP servers to attack the DC Universe Onlinegame server. The timestamps on the tweets (seen inFigure 11) about DC Universe Online and Planetside 2(their intended target), range from 2014-01-01 23:16:11to 2014-01-02 02:48:26. These tweets fit into the timeperiod (seen in Figure 12) of the packets captured inthe ZA1 dataset, which is around 2014-01-01 00:00:00to 2014-01-02 02:00:00. In a forum post [18] ongamefaqs.com, there were complaints of not being able toload the DC Universe Online website.

Figure 11: Tweet by Derp Trolling about DC Universe Online

Figure 12: Packets per hour for DC Universe Online

EA Login Servers: The EA login servers were targeted byDerp Trolling with their tweets (seen in Figure 13) having

‡ https://www.dcuniverseonline.com/home

Page 9: CHARACTERIZATION AND ANALYSIS OF NTP AMPLIFIER TRAFFICaz817975.vo.msecnd.net/wm-418498-cmsimages/ARJJune2016-6-161.pdf · 54 S IN INSI I NINS V107 2 2016 CHARACTERIZATION AND ANALYSIS

Vol.107 (2) June 2016SOUTH AFRICAN INSTITUTE OF ELECTRICAL ENGINEERS62

the timestamps of 2014-01-03 03:00:43 to 2014-01-0305:31:30. The time period of the attack (seen in Figure 14)from the captured packets range from 2014-01-03 04:00:00to 2014-01-03 06:00:00, which is very similar to the DerpTrolling attack tweets (first packet and first tweet with inone hour of each other). In a news article [19], the writersaid at 04:15, that they were not able to access the servers.

Figure 13: Tweet by Derp Trolling about the EA login servers

Figure 14: Packets per hour for EA login servers

Runescape: Runescape‡‡ is a fantasy MMORPG. Thetimestamps of their tweets (seen in Figure 15) range from2013-12-31 16:19:50 to 2013-12-31 17:51:15. Althoughthe correlation between the captured packet’s time span(seen in Figure 16) and the tweets are not as close as theabove two cases, the attack packets and tweets occurredwithin one hour and forty minutes of each other. Thismay be a coincidence, but may be evidence that the ZA1server was not being used until later in the attack. On asubreddit for Runescape [20] there were many complaintsabout connection and lag issues on 31 December, whichcommenters blamed on the DERP Trolling DDoS attack.

EVE Online: EVE Online§ is a massively multiplayeronline (MMO) game set in a futuristic space universe. Thetimestamps on the tweets (refer to Figure 17) range from2013-12-31 20:19:25 to 2013-12-31 21:36:22. The timebetween the tweet and the first packet received (refer toFigure 18) was one hour and forty minutes (as above).This could also be a coincidence, but may show that fortwo hours after the attack started around 20:20, the ZA1server was used to generate extra traffic. In a post on theEve Online forums¶ , one of the game developers postedat 2013-12-31 21:51:24 that were the targets of a DDoSattack. This was followed by other commenters on theforum confirming that they were not able to access thegame.

‡‡ http://www.runescape.com/§ http://www.eveonline.com/¶ https://forums.eveonline.com/default.aspx?g=posts&m=4059746

Figure 15: Tweet by Derp Trolling about Runescape

Figure 16: Packets per hour for Runescape

8. CONCLUSION

This paper has presented initial exploratory analysis oftwo NTP based DDoS attack datasets. The primary focusof this analysis has been the IPv4 Time-to-Live valuesobserved in recorded network packets. Cases were foundwhere multiple origin systems were generating datagramswith spoofed source addresses in order to attack one victimsystem. This attack was was achieved though the thoughthe exploitation of the NTP MONLIST feature whichgenerated a substantal amplification of the original trafficvolumes in response to the spoofed packets. This wasdetermined due to the numerous source addresses observedwith multiple TTL values. Since many of the TTL valuesobserved are >230, it could mean that the attacking hostsare using the same initial TTL of 255. This was confirmedby reviewing the source of several common NTP DDoStools, which explicitly set the TTL field of the generatedpackets to the maximum value. We were also able to inferthe number attackers (or attackers sharing common routingpaths) targeting a certain victim, by finding the TTL usedfor each source address. In addition, the results show thatthese attacks utilise more than one vulnerable NTP serverduring an attack.

It was found that the main targets of these attacks aregaming related servers (as seen in the Derp Trolling casestudy), which is an expected result as gaming servers area major target, particularly in DDoS attacks focusing onbandwidth exhaustion.

Page 10: CHARACTERIZATION AND ANALYSIS OF NTP AMPLIFIER TRAFFICaz817975.vo.msecnd.net/wm-418498-cmsimages/ARJJune2016-6-161.pdf · 54 S IN INSI I NINS V107 2 2016 CHARACTERIZATION AND ANALYSIS

Vol.107 (2) June 2016 SOUTH AFRICAN INSTITUTE OF ELECTRICAL ENGINEERS 63

Figure 17: Tweet by Derp Trolling about Eve Online

Figure 18: Packets per hour for Eve Online

8.1 Future Work

Future work with the datasets described in this work willinclude further analysis. A specific area to be exploredfurther is using the IP datagram and UDP datagram lengthsto further characterise NTP DDoS attacks, with a viewto understanding the popularity of the exploitation toolsused. Linked to the aforementioned exploration, the actualpaylaods can be analyzed and in conjunction with baseTTL’s and packet sizes, be attributed to certain toolsavailable in the wild. An analysis of the packet contentswill also be carried out as well as looking at the sourceports used by the packets and find their uses, which areexpected be game related.

REFERENCES

[1] J. Graham-Cumming. (2014, January)Understanding and mitigating NTP-basedDDoS attacks. Blog Post. CloudFlare.[Accessed: 25 June 2014]. [Online]. Avail-able: https://blog.cloudflare.com/understanding-and-mitigating-ntp-based-ddos-attacks/

[2] D. L. Mills, “Internet time synchronization: theNetwork Time Protocol,” Communications, IEEETransactions on, vol. 39, no. 10, pp. 1482–1493,1991.

[3] C. Rossow, “Amplification hell: Revisiting networkprotocols for DDoS abuse,” in Symposium onNetwork and Distributed System Security (NDSS),2014.

[4] BG.net. (2014, January) ”NTP reflection attack- a vulnerability in implementations ofNTP”. [Accessed: September 2014]. [Online].Available: http://bg.net.ua/content/ntp-reflection-attack-uyazvimost-v-realizatsiyakh-protokola-ntp

[5] K. J. Higgins. (2013, December) Attackers wagenetwork time protocol-based DDoS attacks. NewsArticle:. DarkReading. [Online]. Available: http://www.darkreading.com/attacks-breaches/attackers-wage-network-time-protocol-bas/240165063

[6] M. Prince. (2014) Technical details behinda 400Gbps NTP amplification DDoS attack.Online document. Cloud Flare. [Online]. Avail-able: http://blog.cloudflare.com/technical-details-behind-a-400gbps-ntp-amplification-ddos-attack

[7] M. Mimoso. (2014, June) Dramatic Dropin Vulnerable NTP Servers Used in DDoSAttacks. Online Article. threat post. [Accessedon: 9 October 2015]. [Online]. Available:http://threatpost.com/dramatic-drop-in-vulnerable-ntp-servers-used-in-ddos-attacks/106835

[8] Arbor Networks. (2014, October) Arbor Networks’ATLAS Data Shows Reflection DDoS AttacksContinue to be Significant in Q3 2014.Press Release. Arbor Newtorks. [Accessedon: 9 October 2014]. [Online]. Available:http://www.arbornetworks.com/news-and-events/press-releases/recent-press-releases/5283-arbor-networks-atlas-data-shows-reflection-ddos-attacks-continue-to-be-significant-in-q3-2014

[9] M. Kuhrer, T. Hupperich, C. Rossow, and T. Holz,“Exit from hell? Reducing the impact ofamplification DDoS attacks,” in USENIX SecuritySymposium, 2014.

[10] J. Czyz, M. Kallitsis, M. Gharaibeh,C. Papadopoulos, M. Bailey, and M. Karir,“Taming the 800 pound gorilla: The rise anddecline of ntp ddos attacks,” in Proceedings ofthe 2014 Conference on Internet MeasurementConference, ser. IMC ’14. New York, NY, USA:ACM, 2014, pp. 435–448. [Online]. Available:http://doi.acm.org/10.1145/2663716.2663717

[11] G. Huston. (2014, March) NTP for Evil. Blog post.APNIC. [Accessed on: 9 January 2016 [Online].Available: http://labs.apnic.net/blabs/?p=464

[12] T. Yuzawa. (2014, February) One-liner iptablesrule to Filter NTP Reflection on Linux Hypervisor.[Accessed on: 20 October 2014[. [Online]. Avail-able: http://packetpushers.net/one-liner-iptables-rule-to-filter-ntp-reflection-on-linux-hypervisor/

[13] R. Dobbins and J. Braunegg. (2014, February)Micron21 - NTP Reflection (Amplification) DDoSAttack - Request Packet. Online Article. Micron21.[Accessed on: 25 October 2014]. [Online]. Available:http://www.micron21.com/ddos-ntp.php

Page 11: CHARACTERIZATION AND ANALYSIS OF NTP AMPLIFIER TRAFFICaz817975.vo.msecnd.net/wm-418498-cmsimages/ARJJune2016-6-161.pdf · 54 S IN INSI I NINS V107 2 2016 CHARACTERIZATION AND ANALYSIS

Vol.107 (2) June 2016SOUTH AFRICAN INSTITUTE OF ELECTRICAL ENGINEERS64

[14] NSFOCUS. (2014, February) NTP amplificationattacks are on the rise? (Part1). Blog Post. NSFOCUS. [Accessedon: 12 October 2014]. [Online].Available: http://nsfocusblog.com/2014/02/04/ntp-amplification-attacks-are-on-the-rise-part-1/

[15] StPaddy. (2014, February) VMWare esxi 3.x- High Bandwidth. Online forum. SpiceWorks. [Accessed: September 2014]. [Online].Available: http://community.spiceworks.com/topic/445704-vmware-esxi-3-x-high-bandwidth

[16] Tatung University. IP traffic school. Tatung Univer-sity. [Accessed: September 2014]. [Online]. Avail-able: http://traffic.ttu.edu.tw/gigaflow/extipflow.php?start=2014-02-16&end=2014-02-16&OrderBy=stin

[17] S. Bogos. (2013, December) Update: Hackers BringDown LoL, DoTA 2, Blizzard, EA Servers. NewArticle. The Escapist. [Accessed on: 23 July 2014].

[Online]. Available: http://www.escapistmagazine.com/news/view/130941-Update-Hackers-Bring-Down-LoL-DoTA-2-Blizzard-EA-Servers

[18] xrxleader. (2013, January) Error code 1046.Forum Post. [Accessed on: 12 August 2014].[Online]. Available: http://www.gamefaqs.com/boards/950873-dc-universe-online/68234564

[19] A. Garreffa. (2014, January) DERP takes down EAlogin, Origin is not working at all. News article.[Accessed on: 23 August 2014]. [Online]. Available:http://www.tweaktown.com/news/34601/derp-takes-down-ea-login-origin-is-not-working-at-all/index.html

[20] AlmostNPC. (2013, December) Connection andlLag issues... Forum post. Reddit. [Accessedon: 23 August 2014]. [Online]. Available:https://www.reddit.com/r/runescape/comments/

1u3j34/connection%5C and%5C lag%5C issues/