Finding Perpetrators behind DDoS Attacks
Reflective Amplification Denial-of-Service attacks continue to be a serious threat. We measured roughly 10,000 attacks per day in a post last year, and the numbers have not gone down since: In the first two months of 2019 our honeypot network already saw a total of over 500,000 attacks.
There are two main reasons for the incessant popularity of reflective DDoS attacks:
One, these attacks require comparatively low effort to execute. In contrast to elaborate botnet operations that require a heavy code base and constant maintenance efforts, a reflective DDoS attacks in essence only requires a list of potential reflectors/amplifiers and a few lines of code.
Two, due to their reflective nature, these attacks cannot be easily traced back to their originators. This greatly impedes efforts to shut down the sources of such attacks, both through technical means as well as criminal prosecution.
But is the situation really as hopeless as it seems? It turns out, there actually are ways to find indicators about an attack's true origins that can be derived from a large honeypot network such as the one SISSDEN operates.
The mechanics of reflective DDoS
In a reflective DDoS attack, the attacker sends large amounts of UDP packets to several hundred to thousand reflectors. However, he will spoof the source address of the packets in such a way that, to the reflector, they will appear as legimate requests from the victim. Since UDP is used, the reflector will send its response to the victim right away. To make matters worse, the attacker will usually also pick services where the response sent by the reflector is considerably larger than the request he has to send himself. This leads to an amplification of attack traffic bandwidth, and can increase the attack bandwidth by several orders of magnitude.
Our DDoS honeypots mimic the behaviour of such amplifying reflectors: To the unsuspecting evildoer these appear to be ordinary UDP servers, yet as soon as the honeypot detects unusually large volumes of requests it will cease to send out replies (in order to spare the victim from harm) and log information about the attack instead (which is then fed to the SISSDEN platform).
This also explains why these attacks are notoriously hard to trace back: All traffic the victim can observe comes from exploited reflectors rather than the attacker himself, and all attack traffic that honeypot can observe caries spoofed source addresses.
However, there are a few packets the honeypot can observe that is not spoofed.
As we said before, a necessary prerequisite for a reflective DDoS attack is a list of potential reflectors. In order to find suitable reflectors, scanning is commonly used. One important feature to note is that packets sent during a scan cannot be spoofed -- after all, the scanner is interested in actually receiving any replies himself.
We can leverage this to modify our honeypots slightly: Everytime a honeypot is contacted by a new source address for the first time, it will flip a coin. Based on the result, the honeypot will either reply to this source normally or ignore all of its requests. Thus, if a scanner scans our entire network of DDoS honeypots, it will only find half of them.
While this may seem counterintuitive at first, it leads to a very powerful result: It effectively imposes a fingerprint on individual scanners.
Consider the two scanners in the picture above. Both of them have discovered five honeypots that they can abuse in subsequent DDoS attacks, yet the choice of abused honeypots makes it very clear who provided the necessary data.
This approach of DDoS traceback has been first presented in a research paper a little over two years ago. Within the SISSDEN project, we have adopted this approach and developed it into a continuously running analysis task of our data processing pipeline.
This allows us for example to easily analyze the top sixteen scanners of the last five months:
As can be seen, these few scanners are responsible for a sizeable fraction of daily attacks. Also, data from some scanners is used throughout the entire time, while others only join in for a few weeks.
Hiding a honeypot from half of the Internet can have surprisingly positive results. With this data now being available in the SISSDEN platform, we are looking forward to further interesting analyses as well as new capabilities in mitigating the threat of reflective DDoS.