Honeypot-based monitoring of amplification DDoS attacks

By on 30 Jul 2018

Category: Tech matters

Tags: , , ,

Blog home

The SISSDEN project operates a network of honeypots designed to detect amplification DDoS attacks.

Amplification Distributed Denial of Service (DDoS) attacks are one of the most prevalent forms of DoS attacks. This type of reflective DoS attack abuses two flaws in core networking protocols:

  • IP header information is not authenticated.
  • UDP does not employ a handshake.

The first flaw allows an attacker to spoof requests to a vulnerable service in the name of the victim; the second flaw causes the vulnerable service to answer this request immediately.

The benefit of these attacks for attackers are twofold:

  • Firstly, by using vulnerable services as traffic reflectors, these attacks inherently hide the attacker’s address, thereby hindering prosecution.
  • Secondly, small requests usually suffice to trigger large responses, leading to an amplification in attack bandwidth towards the victim.

Depending on the protocol being abused, an amplification factor of 100x or more can be achieved. Many popular protocols can be abused for this, including DNS, NTP, SSDP and more.

What makes amplification DDoS attacks even more widespread is the fact that such attacks can easily be purchased online from so-called booter services. These websites often operate under the disguise of a legitimate service offering ‘stress-testing capabilities’ to network operators but allow one to freely ‘stress-test’ any IP address for only a small fee.

Observing amplification attacks

The SISSDEN project operates a network of honeypots designed to detect amplification DDoS attacks.

These honeypots mimic vulnerable services with the intent to be ‘abused’ by attackers. However, instead of then relaying attack traffic towards victims, a log message is generated allowing SISSDEN to observe these attacks in near real time.

Over the last year, our honeypots observed between 7,000 and 17,000 amplification attack per day, with an average of about 10,000.

Figure 1 — Number of amplification attacks per day.

Amplification vectors

Breaking these down per protocol reveals some interesting insights (see Figure 2). For example, the first spike in January was mainly caused by an increase in DNS-based attacks, as were the ones at the mid- and end-of March. On the other hand, the spike at the end-of January was caused by CharGen-based attacks, and in mid-April, NTP saw an increase.

Figure 2 — Number of amplification attacks broken down by protocol.

These relations can be better seen in a normalized graph, giving relative percentages between attack protocols (Figure 3). As can be seen, the most prevalent attack vectors are CharGen, DNS, NTP, and SSDP. Two more interesting observations that can be drawn from the graph.

Figure 3 — Number of amplification attacks broken down by protocol, normalized.

Firstly, attackers are quick to find and abuse vulnerable servers. After the amplification vulnerability in memcached was revealed, we added support for memcached to our honeypot, with a rollout in the first days of March. Only a few days later, memcached can be seen to constitute a notable fraction of attacks observed by our honeypots, meaning that attackers found and added our honeypots to their list of reflectors.

Read: Understanding the facts of memcached amplification attacks

Secondly, many of these attacks seem to stem from booter services. This can be seen as there is a notable decrease in DNS-based attacks towards the end of April, which coincides very well with Europol’s actions against webstresser, one of the biggest booter services to date.

Attack durations

Interestingly, amplification attacks are not very long-lasting. More than 90% of attacks are shorter than 1 hour, and more than half last less than 5 minutes. In fact, 20% of all attacks are shorter than 1 minute.

Figure 4 — Duration of amplification attacks.

Looking at the duration of amplification attacks gives another indication of automated attacks, visible as almost step-wise increases around 1 and 5 minutes, respectively. As booter services often only allow selection of an attack duration from a predefined list, one would expect to see these steps in the above graph. This is further confirmed by similar steps around 30 seconds, 10 minutes, 20 minutes, and 1 hour.

Attack repetitions

On the upside, victims that experience amplification attacks are unlikely to do so more than once. In fact, over 75% of all victim addresses observed by our honeypots were targeted only once, and less than 5% saw more than 5 attacks (see Figure 5).

Figure 5 — Number of attacks per victim address.

Attack victims

To get a better understanding of who is being targeted by these attacks, one can plot all the IP addresses into a 2D-plane using a space-filling curve, such as the Hilbert curve (see an example here). Choosing a scale where one pixel corresponds to a /16 network, the entire IPv4 space can then be plotted on a 256×256 grid, with brighter colours corresponding to a higher number of attacks in the given network.

Figure 6 — Hilbert curve showing which parts of the IPv4 address space are suffering mostly from attacks.

Comparing the above graphs with the allocated ranges shows that the only non-attacked (dark) areas in the graph mostly correspond to reserved or unused IP space (such as or


Amplification attacks are still one of the most prevalent threats in 2018, with more than 10,000 attacks observed on a daily basis, targeting Internet participants worldwide. However, most of these attacks seem to stem from booter services, indicating that continued effort in their take-down will eventually lead to a reduction in DDoS attacks.

Adapted from original post that appeared on RIPE Labs Blog.

Johannes Krupp is is a researcher at the centre for IT-Security, Privacy, and Accountability (CISPA) in Saarbrücken, Germany.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *