CHARACTERIZATION AND ANALYSIS OF NTP AMPLIFIER TRAFFIC

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: g11r0252@campus.ru.ac.za Security and Networks Research Group, Dept. of Computer Science, Rhodes University, Grahamstown 6139, South Africa E-mail: b.irwin@ru.ac.za 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

55 the source IP address [9]. More detailed analysis of such attacks is therefore important in order to gain information which may be valuable in mitigating or finding the source of an attack. In this paper a number of characteristics of the attacks are looked at. The primary focus, however, relates to the observed TTL values within the IP header. The analysis of these has shown that they can be used to provide insight on how many hosts are being used to generate request 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 Denial of Service and NTP based Denial of Service attacks in particular. The data sources used and analysis process undertaken are described in Section 3. Results of the analysis of the two datasets are presented in Sections 4 and 5 respectively. Two brief case studies arising out of the analysis of the combined data are presented in Section 6. The paper concludes with Section 7, which also considers possible future work. address, source port, UDP header size and IP datagram size were also analyzed. The purpose of this was to determine the victims of the attacks in a similar manner to that used in [10]. 3.1 Data Sources The analysis carried out and presented in the remainder of this paper was based on two packet captures obtained from systems running a vulnerable version of the NTP software (NTP 4.2.6 or below). Packet captures were recorded using tcpdump. Packets that did not contain a source or destination port of 123/udp were filtered out prior to analysis as they did not contain a MONLIST request or reply and would not have contacted a vulnerable NTP server for potential amplification. Both datasets were collected within South African IPv4 address space, contained within AS2018 (TENET). An overview of the logical capture setup is shown in Figure 2. 2. RELATED WORK Czyz et al. [10], reported on their analysis of NTP DDoS attacks which were were analyzed on a global scale. This was achieved by looking at the rise of NTP amplification attacks, how many amplifiers there were, and their amplification scale. The victims of the attacks were found by looking at the source port of the original attack packets. It was found that most targets were related to online gaming, with victims including Minecraft, Runescape and Microsoft Xbox live service. The most popular source port was port 80/udp which, as they stated, may have been used to target games that use this port or websites. When classifying the number of attacks that occurred throughout a 15-week period, while monitoring a number of amplifiers, a simplification was used by classifying each unique targeted IP in a week-long sample as one attack. This simplification does not take into account attacks targeting network blocks or a single IP hosting multiple sites. In relation to TTL analysis it was determined by [10] that most of the attack traffic from a Colorado State University dataset appeared to originate from Windows-based machines and that they are probably computers in a botnet. This is because the mode of the IPv4 TTL field was observed to be 109, and the default initial TTL set on Microsoft Windows platforms is 128. What these researchers failed to mention was that the attackers could have been using a DDoS tool that could have set the initial TTL to 128 or slightly above. 3. RESEARCH At the time of the research being conducted in early 2014, there had not been much in-depth research into the interplay of TTL values and NTP DDoS. The driver behind this research was to investigate a number of packet characteristics relating to the observed TTL values of recorded inbound traffic. In addition, the source IP Figure 2: Capture points of the two datasets ZA1: The ZA1 data set consists of data collected between 15 July 2013 and 9 March 2014. The capture files have a combined size of 3.2 GB and contain a total of 32 799 299 packets. The captures show two attacks lasting around two weeks each. These were observed in the periods 23 December 2013 to 7 January 2014 and 10-25 February 2014 respectively. This dataset is of interest as the data capture was initiated pre-exploitation, and contains traffic destined for a single IP address. ZA2: The capture files constituting the ZA2 dataset

56 consisted of 103 060 564 packets in total amounting to 11.5 GB, which were captured over a period of just over one month, from 12 February 2014 to 10 March 2014. This data was captured after the initially detected attack had been mitigated. It contains both request and reply MONLIST packets and sees a larger number of packets per hour compared to ZA1. This is partially due to the fact that it was collected by recording traffic for the majority of target IP addresses within a single /27 IPv4 net block. For the purposes of this paper, the analysis across addresses has been merged, and individual activity has not been analysed. 3.2 Analysis Tools Analysis was performed using a series of custom developed tools which were implemented in Python. This toolchain was used to parse and extract data from the raw packet captures, and then filter and plot time series graphs of information such as packets per hour, unique hosts per hour, IP addresses with a certain TTL, TTL per hour, IP datagram length, UDP datagram length, TTL frequency and others. The tools also outputted.csv files of the ranked source data which was be used for processing and analysis of the data in other tools. 3.3 Address Disclosure The IP addresses reported in this research are those observed as source addressed of the datagrams attempting to exploit NTP systems within the two monitored networks. In the vast majority of cases these can reliably be determined to be the spoofed addresses of the attackers intended targets. These addresses have not been blinded or obscured, as the attacks against these organisations have have been well publicized and documented. Current addressing information can be trivially obtained using common search tools and DNS resolution. IT is felt that the disclosure fo the addresses may help other researchers in future efforts around correlation of data relating to victims of such attacks. Table 1: Top 10 IP addresses from ZA1 Rank IP address Count % TTL 46 (9.21%) 1 217.168.137.25 3 896 074 11.88 47 (1.85%) 50 (88.54%) 2 72.46.150.210 320 816 0.98 3 64.37.171.32 257 066 0.78 111 4 85.17.207.236 253 588 0.77 111 5 159.153.228.77 228 753 0.7 111 6 62.67.0.130 204 174 0.62 111 7 192.95.11.54 189 224 0.58 111 111 (98.73%) 8 63.251.20.99 163 830 0.5 232 (0.25%) 234 (1.20%) 9 212.143.95.26 154 368 0.47 111 10 75.126.29.106 150 659 0.46 111 Total 5 818 552 % 17.74% in order to get the maximum amplification scale for the attack using the NTP MONLIST command, there must have been over 600 historical connections to the server which can then be sent in response to the forged packet. The remainder of the section considers specific attributes of the observed attack traffic. Figure 3: Packets per hour for ZA1 4. ZA1 ANALYSIS This section presents the results of the analysis conducted on the ZA1 dataset. Two periods of exploitation were during the observed period were determined to be 23 December 2013 to 7 January 2014 and 10-25 February 2014. These can be seen clearly in Figure 3. Peak packet rates in excess of 500 000 packets/hour were observed in the initial attack. Packet rates subsequently decreased to around 50 000 packets/hour for the remainder of the attack. Significant diurnal trends were observed in the second phase. These patterns can be similarly observed in Figure 4 which plots the number of unique source hosts observed during each hour period. For both attacks the unique hosts started off with a considerably higher value than the rest of the unique host values of the attack. This is possibly due to attackers priming the NTP servers (by flooding with generated queries from different source addresses), 4.1 Source IP and TTL Figure 4: Unique hosts per hour An analysis of the observed source addresses shows that a single address (217.168.137.25) was observed at a level in excess of an order of magnitude more than the other top sources with its packets taking up 11% of the total packets observed. This target address is located in Poland, and was most likely hosting online gaming services. However at the time of the analysis, the system had been taken offline, and as such is it is not possible to confirm this. Table 1 lists the traffic for the top 10 observed sources, which

57 Table 2: Top 10 TTL values for ZA1 Rank TTL Packet Count % of total Initial TTL 1 111 25 771 844 78.57 128 2 50 3 575 563 10.9 60 or 64 3 236 920 462 2.81 255 4 234 864 950 2.64 255 5 232 434 480 1.32 255 6 46 359 082 1.09 60 or 64 7 237 111 038 0.34 255 8 242 82 377 0.25 255 9 62 78 255 0.24 60 or 64 10 47 71 969 0.22 60 or 64 Total 32 270 020 % of total 98.39% constitute 17.74% of the overall traffic. This indicates that the IP address was targeted from the beginning of the attack, and the varying TTL values observed further show a strong likelihood that more than one host was being used to spoof packets with this source address. The TTL values found in packets using the top IP address could indicate three different attacking hosts or one host with rerouted packets. As shown in the Table 1, there are only two IP addresses where more than a single TTL value was observed. This is indicative of multiple participants spoofing the address, or minor routing changes having occurred during the attack. Further investigation into the temporal overlap is discussed in future work. Taking a look at the IP address 63.251.20.99, it can be seen that there is a distinct difference between the observed TTL values. Although the majority of the packets have a TTL of 111 (in common with the majority of traffic) there are some with a very 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. The most frequent of these being 111, which could mean the attacker was using a Windows operating system (assuming the TTL is not spoofed) as Windows sets the initial TTL to 128. This is a similar result to [10] and may indicate a botnet being used or one host attacking multiple victims. 4.3 TTL Groups Based on the top 10 TTL values shown in Table 2, the IP addresses for which two or more TTLs were observed were isolated. This resulted in 4 679 IP addresses out of the 56 273 IP source addresses being observed with multiple TTL values, which comprises of just over 8%. The isolated IP addresses and their observed TTLs were analysed to find which 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 most frequent being the TTL values of 234 and 236 with 3 207 IP addresses observed. Although not shown in Table 3, Table 3: Top 10 TTL ranges in ZA1 Rank TTL group Unique IP % of total 1 234, 36 3207 68.54 2 232, 236 245 5.24 3 111, 236 232 4.96 4 232, 234, 236 201 4.3 5 111, 234 116 3.55 6 111, 234, 236 97 2.07 7 232, 234 72 1.54 8 234, 236, 237 72 1.54 9 236, 237 54 1.15 10 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 observed with only four IP addresses. The number of distinct TTL values observed within a group (all claiming to be from a single IP source address) is strongly indicative of multiple hosts being involved in generating the attack traffic. While the data shows that multiple hosts are likely involved it is difficult to determine with any certainty as to the exact number given the vagaries of Internet routing. As such, the first ranked TTL group in Table 3 could indicate that two hosts were possibly attacking 3 207 different IP addresses (the spoofed source address being that of the target of the amplification attack). It could also indicate that the hosts attacking the 3 207 IP addresses were 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 could be two groups of hosts generating the spoofed traffic. 4.4 Full packet size The packet sizes were analysed because there are a small number of NTP DDoS tools and there are two sizes of packet sizes generated by them, so this may be useful in determining a probable tool and learning more about an attacker. The ZA1 dataset contained five distinct packet lengths, shown in the x-axis of Figure 5. The most frequent length being 60 bytes, which according to [11] [12], could indicate that the attacker was using a Perl based DDoS or a Python based tool named ntpdos.py. The Perl tool is the only DDoS tool out of the previously mentioned three, to explicitly set its TTL value to 255 (instead of relying on the OS default). We can therefore assume with a fairly high degree of certainty that the 60 bytes packets, whose TTLs were above 230, were generated from this tool. The observed packet payloads for this traffic also match the Perl tool. The next most frequent packet length observed is 234 http://goo.gl/mpdu97 https://goo.gl/qzlnxc https://goo.gl/9qaaun

58 bytes, which according to [13] can be generated by a Python program called ntp MONLIST.py or with the use of a special query program which is part of the NTP software suite ntpdc. This program can be used to create a MONLIST request of 234 bytes according to [11] [12]. This program s MONLIST command and the resulting query datagram can be used in a script that generates large number of the requests, as has been done with the Python script which just encapsulated the query as generated by ntpdc. As shown in Figure 5, the packets that have a length of 234 bytes also have TTL values of 46, 47 and 50 (the other four values can be ignored as their observed packet count is below ten and this can be regarded as anomalous). When a MONLIST request is sent to a server, that has a full list of hosts that have connected to it, the reply packets are 482 bytes each [14]. Figure 5: Full packet length per TTL value for ZA1 5. ZA2 ANALYSIS Figure 6: Packets per hour for ZA2 time period than the ZA1 set, contains nearly three times the volume of traffic, and shows sustained attack traffic over the period. As noted in Section 3.1, this merges attack traffic across a number of hosts within a /27 net block. The volume of the observed traffic is shown in Figure 6; however this lacks the clear break in attacks as seen previously in Figure 3. This attack saw a peak packet per hour rate of around 2 million, which is significantly larger than the peak rate of ZA1 (although it is acknowledged that there are a larger number of targets in this sample). Figure 7 shows a similar diurnal pattern as seen in Figure 4. Another similarity between the two unique source hosts per hour plots is the considerably high packet count at the start of the capture. 5.1 Source IP and TTL As shown in Table 4, which lists the traffic for the top 10 observed sources, as was found in the ZA1 analysis, there is one IP address (217.168.137.25) that is observed at a level in excess of an order of magnitude more than the other top sources. This address was also observed with a high count on other or monitored NTP servers around the world around during the same time period [4] [15] [16]. The TTL values observed for packets originating from 217.168.137.25 were 47, 51 and 48, which are similar TTL values for this IP address in ZA1. This is indicative of multiple participants spoofing the address, minor routing occurring during the attack or the attackers used a similar DDoS tool. Most importantly, it shows the exploitation of multiple servers used as reflectors in amplification attacks against targets since the same source IPs were observed in both datasets. Unlike the ZA1 dataset where only two of the top 10 source addresses were observed with more than one TTL, the ZA2 dataset shows all top 10 source addresses having traffic with at least two, and in most cases, more than five distinct TTL values. This strongly supports the supposition that more than one attack source was used to generate attack traffic to be reflected and amplified towards the intended victim. In addition the exploited NTP servers were used in the attack of multiple target hosts. 5.2 Time-to-Live values Figure 7: Unique hosts per hour for ZA2 This section presents results of the analysis conducted on the ZA2 dataset. The dataset, which spans a shorter overall https://goo.gl/sufsrs http://doc.ntp.org/4.1.2/ntpdc.htm A total of 248 distinct TTL values were observed. The most frequent being 236, which could mean the attacker was using a tool that sets the initial TTL to the maximum of 255, rather than relying on the operating system defaults. Table 5 shows the top 10 TTLs observed in the ZA2 dataset. Eight of the top 10 TTLs are < 230, which suggests the initial TTL was set to 255. The Perl NTP DDoS tool mentioned in Section 4.4 could have been used here. The TTL of 64, seen in Table 5, is the initial TTL of the NTP servers. This TTL signifies all the traffic that has been reflected by the servers.

59 Table 4: Top 10 IP addresses from ZA2 % Rank IP address Count of total TTL 47 (9.67%) 1 217.168.137.25 18 565 847 18.01 51 (87.98%) 232 (6.18%) 233 (7.93%) 2 162.218.54.28 3 158 997 3.07 234 (69.82%) 235 (2.29%) 236 (7.37%) 238 (6.41%) 234 (8.26%) 235 (9.02%) 3 192.64.169.29 2 322 018 2.25 236 (73.58%) 237 (0.87%) 243 (0.41%) 233 (0.37%) 235 (9.60%) 4 178.32.140.23 1 820 792 1.77 236 (66.99%) 237 (4.25%) 238 (14.65%) 243 (0.84%) 232 (31.15%) 233(11.37%) 5 198.50.180.205 1 495 278 1.45 235 (2.51%) 236 (54.86%) 238 (0.10%) 6 37.187.77.125 1 210 377 1.17 235 (77.27%) 238 (11.26%) 236 (8.34%) 237 (2.95%) 232 (0.38%) 233 (6.22%) 7 178.32.137.207 825 674 0.8 235 (19.09%) 236 (65.16%) 237 (4.28%) 243 (1.43%) 233 (3.31%) 8 94.23.19.43 751 176 0.73 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%) 236 (43.53%) 233 (14.69%) 10 198.27.74.181 677 972 0.66 232 (2.36%) 234 (19.20) 235 (20.22%) Total 31 510 837 % of total 30.58% Table 5: Top 10 TTL values for ZA2 Rank TTL Packet Count % of total Initial TTL 1 236 23 509 039 22.81 255 2 235 17 009 527 16.5 255 3 51 16 778 624 16.28 60 or 64 4 237 13 946 335 13.53 255 5 232 4 054 193 3.93 255 6 234 3 893 500 3.78 255 7 238 2 755 487 2.67 255 8 243 2 451 201 238 255 9 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 ZA2 Rank TTL group Unique IPs % of total 1 235, 237 3 440 38.99 2 233, 237 244 2.77 3 233, 235, 237 167 1.89 4 234, 237 137 1.55 5 236, 237 131 1.48 6 234, 235, 237 93 1.05 7 232, 234 88 1.00 8 237, 64 88 1.00 9 235,236, 237 69 0.78 10 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), the IP addresses which used two or more TTLs were found. This resulted in 8 823 IP addresses out of the 38 634 IP addresses seen. There were 143 different groups of TTLs found, the top 10 of which are shown in Table 6. The most frequent being 235 and 237 with 3 440 IP addresses observed using only these. Although not shown in Table 6 the largest group of top 10 TTLs included of nine out of the top 10 TTLs (232, 233, 234, 235, 236, 237, 238, 51, 64) however, only one (spoofed) IP address was observed to be part of this grouping. This again illustrates the strong evidence towards multiple sources for the spoofed traffic. 5.4 Full packet size The ZA2 dataset showed similar results to ZA1 and contained 12 distinct full packet sizes, shown in Figure 8. The most frequent being 60 bytes, which is the same result as observed in the ZA1 dataset. As previously stated in Section 4.4, this length could indicate the use of a Perl or Python tool. In Figure 8, it is observed that 8 out of 9 of the TTL values seen with a full packet size of 60 bytes are around 230, which is indicative of the use of the Perl tool, because this tool sets the TTL field to 255 and generates packets of 60 bytes.

60 As seen in ZA1 and ZA2, and seen in 8, the second most frequent packet size is 234 bytes. Packets observed with this size were most likely generated by the ntp MONLIST.py or ntpdc programs. The most frequent TTL seen in packets of 234 bytes is 51, which is the TTL that is observed for the top IP address. This is a similar result to ZA1, where the most frequent TTL seen in the 234 byte packets are 46, 47 and 50, which are also the TTLs observed for the top IP address. Because the ZA2 dataset contains request and reflected packets, a packet length of 482 is observed. Packets with this length are only obseved with a TTL of 64, which is the initial TTL for ZA2 server. These packets are the reflected packets that are generated from the 60 and 234 byte request packets. In the case when the MONLIST table was not yet full, the 122, 194, 266, 338, 410 byte packets could indicate the reply packet sizes as the NTP monitor list grew longer. Table 7: TTL values for 217.168.137.25 in the ZA1 dataset Rank TTL Count % 1 50 3 449 705 88.54 2 46 358 966 9.21 3 47 71 933 1.85 4 51 15 395 0.4 5 54 49 0.0013 6 48 18 0.0005 7 49 5 0.0001 8 45 2 0.00 9 53 1 0.00 Total: 3 896 074 Table 8: TTL values for 217.168.137.25 in the ZA2 dataset Rank TTL Count % 1 51 16 334 079 87.98 2 47 1 794 768 9.67 3 48 359 660 1.94 4 52 76 880 0.41 5 55 295 0.0015 6 49 125 0.0007 7 50 35 0.0002 8 54 5 0.00 Total: 18 565 847 Figure 8: Full packet length per TTL value for ZA2 6. COMMON CHARACTERISTICS This section briefly discussed the similarities of the two datasets. The first similarity found was observed in Section 4 and 5, between the unique hosts per hour, where there was a large spike of over 600 unique hosts per hour at the start of each attack illustrated in Figure 4 and 7. As stated previously, this is possibly due to attackers priming the NTP servers, in order to get the maximum amplification scale from the MONLIST command. The top IP address seen in ZA1 was also the top IP address for ZA2. This fact will be explored further in Section 7.1, where it will be shown that the address is being attacked by the same attacker. Although not shown in this paper, the top 20 domain names of the source addresses and the top 20 source ports for ZA1 and ZA2 indicate that the majority of the targets are online gaming related. Out of the top 20 source ports, ZA1 and ZA2 had 13 ports in common, with most of them being common online gaming ports. Taking a look at the top 10 TTLs listed in Table 2 and Table 5 it is observed that ZA1 has 5 TTLs and and ZA2 has 8 TTLs whose values are above 230. Together with the information from Figure 5 and Figure 8 it was found that the attackers that used the ZA1 and ZA2 servers were using the Perl DDoS tool. 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 dataset and the similarities of the results found. The second case study is about a group who call themselves Derp Trolling and the evidence showing that they may have used the vulnerable server in ZA1 to carry out DDoS attacks on online gaming related IP addresses. 7.1 Top IP address The IP address (217.168.137.25) was observed as the top IP address in both the ZA1 and ZA2 datasets. As shown in Tables 7 and 8, the TTL values seen in the ZA1 dataset are one less than the TTLs seen in the ZA2 dataset (an exception being the TTL of 45 in Table 7). This is because the ZA1 data capture point was one more hop away as shown in Figure 2. Looking at the percentages of each of the TTL values in the Tables, it can be seen that the percentages are extremely similar. This is a factor that made it possible that both of the datasets contained packets from the same attacker. Since there is one dominant TTL value, it strongly supports the rerouting of packets. Figure 9 and 10, which show the packets per hour of the top IP address (separated by coloured TTL values). Because the ZA1 and ZA2 capture points were one hop apart from the attacker, the colours

61 were changed accordingly. This produced two very similar graphs, which show the rerouting of packets during the attack. What must be noted is that although they are the same shape, the ZA2 dataset has a higher packet count which stayed steady around 107 000 packets per hour. This is nearly five times as many packets as the ZA1 dataset that saw a steady 21 400 packets per hour. This difference may be because of bandwidth changes. Because the ZA2 dataset was captured after the attack had started, Figure 10 does not show packets from the beginning of the attack, but they would most likely have the same shape as the start of Figure 9. The evidence shown throughout the two dataset analyses, and the above information given in this section leads the authors to the conclusion that there was one coordinated group of attackers using multiple vulnerable NTP servers for amplification. A portion of this attack traffic was captured by the packer loggers which resulted in the ZA1 and ZA2 datasets. names of the top 20 source addresses and noticing that many of the domains were game related. After searching online for DDoS attacks on DC universe online, all the search results pointed at Derp Trolling. These posts fall within the times frames of the attack traffic observed in the ZA1 dataset. While its impossible to prove that the observed traffic was definitiavely the result of activities by this group, the precise timing, and choice of targets, have a high correlation with their posted activity reports. After finding their twitter page, it was clear that many of the other top 20 source addresses were related to their attacks during the period of observation. DC Universe Online: DC Universe Online is a massively multiplayer online role-playing game (MMORPG). Derp Trolling may have used the ZA1 server along with other vulnerable NTP servers to attack the DC Universe Online game server. The timestamps on the tweets (seen in Figure 11) about DC Universe Online and Planetside 2 (their intended target), range from 2014-01-01 23:16:11 to 2014-01-02 02:48:26. These tweets fit into the time period (seen in Figure 12) of the packets captured in the ZA1 dataset, which is around 2014-01-01 00:00:00 to 2014-01-02 02:00:00. In a forum post [18] on gamefaqs.com, there were complaints of not being able to load the DC Universe Online website. Figure 9: Packets per hour for ZA2 Figure 11: Tweet by Derp Trolling about DC Universe Online Figure 10: Packets per hour for ZA2 7.2 Derp Trolling Derp Trolling or Derp for short, is the name of a hacker group that carried out numerous DDoS attacks from late 2013 and throughout 2014 mainly targeting gaming related servers [17]. Their twitter account is full of tweets about their previous attacks. The account however stopped tweeting about attacks in August 2014, and the hacker claims to have become a white hat hacker. The next few paragraphs show the observations that make it likely that this hacker group used the ZA1 server as a reflector in their attacks. The group was found when looking at the domain https://twitter.com/derptrolling Figure 12: Packets per hour for DC Universe Online EA Login Servers: The EA login servers were targeted by Derp Trolling with their tweets (seen in Figure 13) having https://www.dcuniverseonline.com/home

62 the timestamps of 2014-01-03 03:00:43 to 2014-01-03 05:31:30. The time period of the attack (seen in Figure 14) from the captured packets range from 2014-01-03 04:00:00 to 2014-01-03 06:00:00, which is very similar to the Derp Trolling attack tweets (first packet and first tweet with in one hour of each other). In a news article [19], the writer said at 04:15, that they were not able to access the servers. Figure 13: Tweet by Derp Trolling about the EA login servers Figure 15: Tweet by Derp Trolling about Runescape Figure 14: Packets per hour for EA login servers Runescape: Runescape is a fantasy MMORPG. The timestamps of their tweets (seen in Figure 15) range from 2013-12-31 16:19:50 to 2013-12-31 17:51:15. Although the correlation between the captured packet s time span (seen in Figure 16) and the tweets are not as close as the above two cases, the attack packets and tweets occurred within one hour and forty minutes of each other. This may be a coincidence, but may be evidence that the ZA1 server was not being used until later in the attack. On a subreddit for Runescape [20] there were many complaints about connection and lag issues on 31 December, which commenters blamed on the DERP Trolling DDoS attack. EVE Online: EVE Online is a massively multiplayer online (MMO) game set in a futuristic space universe. The timestamps on the tweets (refer to Figure 17) range from 2013-12-31 20:19:25 to 2013-12-31 21:36:22. The time between the tweet and the first packet received (refer to Figure 18) was one hour and forty minutes (as above). This could also be a coincidence, but may show that for two hours after the attack started around 20:20, the ZA1 server was used to generate extra traffic. In a post on the Eve Online forums, one of the game developers posted at 2013-12-31 21:51:24 that were the targets of a DDoS attack. This was followed by other commenters on the forum confirming that they were not able to access the game. http://www.runescape.com/ http://www.eveonline.com/ https://forums.eveonline.com/default.aspx?g=posts&m=4059746 Figure 16: Packets per hour for Runescape 8. CONCLUSION This paper has presented initial exploratory analysis of two NTP based DDoS attack datasets. The primary focus of this analysis has been the IPv4 Time-to-Live values observed in recorded network packets. Cases were found where multiple origin systems were generating datagrams with spoofed source addresses in order to attack one victim system. This attack was was achieved though the though the exploitation of the NTP MONLIST feature which generated a substantal amplification of the original traffic volumes in response to the spoofed packets. This was determined due to the numerous source addresses observed with multiple TTL values. Since many of the TTL values observed are >230, it could mean that the attacking hosts are using the same initial TTL of 255. This was confirmed by reviewing the source of several common NTP DDoS tools, which explicitly set the TTL field of the generated packets to the maximum value. We were also able to infer the number attackers (or attackers sharing common routing paths) targeting a certain victim, by finding the TTL used for each source address. In addition, the results show that these attacks utilise more than one vulnerable NTP server during an attack. It was found that the main targets of these attacks are gaming related servers (as seen in the Derp Trolling case study), which is an expected result as gaming servers are a major target, particularly in DDoS attacks focusing on bandwidth exhaustion.

63 Figure 17: Tweet by Derp Trolling about Eve Online 8.1 Future Work Figure 18: Packets per hour for Eve Online Future work with the datasets described in this work will include further analysis. A specific area to be explored further is using the IP datagram and UDP datagram lengths to further characterise NTP DDoS attacks, with a view to understanding the popularity of the exploitation tools used. Linked to the aforementioned exploration, the actual paylaods can be analyzed and in conjunction with base TTL s and packet sizes, be attributed to certain tools available in the wild. An analysis of the packet contents will also be carried out as well as looking at the source ports used by the packets and find their uses, which are expected be game related. REFERENCES [2] D. L. Mills, Internet time synchronization: the Network Time Protocol, Communications, IEEE Transactions on, vol. 39, no. 10, pp. 1482 1493, 1991. [3] C. Rossow, Amplification hell: Revisiting network protocols for DDoS abuse, in Symposium on Network and Distributed System Security (NDSS), 2014. [1] J. Graham-Cumming. (2014, January) Understanding and mitigating NTP-based DDoS attacks. Blog Post. CloudFlare. [Accessed: 25 June 2014]. [Online]. Available: https://blog.cloudflare.com/understanding-andmitigating-ntp-based-ddos-attacks/ [4] BG.net. (2014, January) NTP reflection attack - a vulnerability in implementations of NTP. [Accessed: September 2014]. [Online]. Available: http://bg.net.ua/content/ntp-reflectionattack-uyazvimost-v-realizatsiyakh-protokola-ntp [5] K. J. Higgins. (2013, December) Attackers wage network time protocol-based DDoS attacks. News Article:. DarkReading. [Online]. Available: http: //www.darkreading.com/attacks-breaches/attackerswage-network-time-protocol-bas/240165063 [6] M. Prince. (2014) Technical details behind a 400Gbps NTP amplification DDoS attack. Online document. Cloud Flare. [Online]. Available: http://blog.cloudflare.com/technical-detailsbehind-a-400gbps-ntp-amplification-ddos-attack [7] M. Mimoso. (2014, June) Dramatic Drop in Vulnerable NTP Servers Used in DDoS Attacks. Online Article. threat post. [Accessed on: 9 October 2015]. [Online]. Available: http://threatpost.com/dramatic-drop-in-vulnerablentp-servers-used-in-ddos-attacks/106835 [8] Arbor Networks. (2014, October) Arbor Networks ATLAS Data Shows Reflection DDoS Attacks Continue to be Significant in Q3 2014. Press Release. Arbor Newtorks. [Accessed on: 9 October 2014]. [Online]. Available: http://www.arbornetworks.com/news-and- events/press-releases/recent-press-releases/5283- arbor-networks-atlas-data-shows-reflection-ddosattacks-continue-to-be-significant-in-q3-2014 [9] M. Kührer, T. Hupperich, C. Rossow, and T. Holz, Exit from hell? Reducing the impact of amplification DDoS attacks, in USENIX Security Symposium, 2014. [10] J. Czyz, M. Kallitsis, M. Gharaibeh, C. Papadopoulos, M. Bailey, and M. Karir, Taming the 800 pound gorilla: The rise and decline of ntp ddos attacks, in Proceedings of the 2014 Conference on Internet Measurement Conference, 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 iptables rule to Filter NTP Reflection on Linux Hypervisor. [Accessed on: 20 October 2014[. [Online]. Available: http://packetpushers.net/one-liner-iptablesrule-to-filter-ntp-reflection-on-linux-hypervisor/ [13] R. Dobbins and J. Braunegg. (2014, February) Micron21 - NTP Reflection (Amplification) DDoS Attack - Request Packet. Online Article. Micron21. [Accessed on: 25 October 2014]. [Online]. Available: http://www.micron21.com/ddos-ntp.php

64 [14] NSFOCUS. (2014, February) NTP amplification attacks are on the rise? (Part 1). Blog Post. NSFOCUS. [Accessed on: 12 October 2014]. [Online]. Available: http://nsfocusblog.com/2014/02/04/ntpamplification-attacks-are-on-the-rise-part-1/ [15] StPaddy. (2014, February) VMWare esxi 3.x - High Bandwidth. Online forum. Spice Works. [Accessed: September 2014]. [Online]. Available: http://community.spiceworks.com/topic/ 445704-vmware-esxi-3-x-high-bandwidth [16] Tatung University. IP traffic school. Tatung University. [Accessed: September 2014]. [Online]. Available: 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 Bring Down LoL, DoTA 2, Blizzard, EA Servers. New Article. 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 EA login, Origin is not working at all. News article. [Accessed on: 23 August 2014]. [Online]. Available: http://www.tweaktown.com/news/34601/derptakes-down-ea-login-origin-is-not-working-atall/index.html [20] AlmostNPC. (2013, December) Connection and llag issues... Forum post. Reddit. [Accessed on: 23 August 2014]. [Online]. Available: https://www.reddit.com/r/runescape/comments/ 1u3j34/connection%5C and%5c lag%5c issues/