TCP Reflection Attacks: Then and Now

We recently published a blog post about the rise in TCP reflection attacks throughout 2019. The public was able to observe the reflection campaign’s targeting of different verticals because the criminal(s) behind the attacks are leveraging public infrastructure as their refractors. 

Ultimately, we published our insight into these campaigns because of their impact on both primary and secondary targets, resulting in service degradation and the blacklisting of misrepresented IP addresses.  

A Brief History Lesson

Refection attacks that gain amplification are nothing new. In fact, one of the original reflection attacks was called a Smurf Attack and authored by Dan Moschuk, aka TFreak, in the late 90’s. A Smurf Attack was a Distributed and Reflective Denial of Service (DrDoS) attack that involved broadcasting ICMP echo requests (Ping) to a wide range of network devices with a spoofed source address. As a result, most of the devices that received this falsified request would respond with an echo reply to the spoofed source, generating a high rate of ICMP traffic that would flood the victim’s devices.

TFreak also authored the Fraggle attack, a variation of the Smurf attack that involved reflecting spoofed UDP traffic off of port 7 (ping) and 19 (Chargen). As time progressed, these two attack vectors from the 90’s became so easy to mitigate, they were no longer effective and bot herders began searching for different methods.

[You may also like: Threat Alert: TCP Amplification Attacks]

The Next Breakthrough

It wasn’t long until the next breakthrough occurred. In 2002, SC Magazine covered the growth in a piece called ‘A next-generation DoS Attack: Distributed Reflections’, which covered the evolution of SYN flood attacks to include a reflection technique.

SYN flood attacks at the time were not distributed in the terms we know today. In the early 2000’s a single attacker or an attacker with a network of compromised PC’s, also known as a botnet, would leverage their resources to send multiple SYN floods to a single target. As the attack vector landscape evolved, attackers learned how to launch spoofed SYN floods with reflective properties. Instead of bouncing a spoofed SYN packet off of their primary target resulting in a half open connection with a random IP, attackers reversed the process and leveraged random network devices as reflectors to send a SYN-ACK vs. a spoofed SYN packet to their primary target.

[You may also like: Happy Dyn Attack Anniversary!]

At the time, it was known that network devices would re-transmit packets if a response was not received. This feature was designed to account for packet loss, but it was assumed that devices would only re-transmit a packet five times, the default setting. Amplified TCP attacks were not a major concern because a TCP flood had different objectives than a UDP flood.

In general, UDP floods aim to degrade services by flooding network pipes with junk traffic so that legitimate traffic can’t reach its destination. TCP floods aim to degrade services by exhausting network resources so legitimate user requests cannot be processed. At the time, TCP floods did not need to generate a large amount of volume as long as the packet rate consumed the network resources available.

Over the years, TCP-based attack vectors fell out of favor as mitigation defenses evolved and resources expanded. The main objective of a DoS attack is to cause an outage, but if mitigation improves, or if the target is well defended, an attacker’s next step is to flood the network pipes.

This is where reflective and amplified UDP attack vectors have come into play over the last few years. Attack vectors abusing the UDP application layers of DNS, NTP, CLDAP and Memcached produce large bandwidth amplification factors that have resulted in the largest DDoS attacks on record.

And Today…

But times have changed again, mitigation has and will always improve, leaving criminals once again looking for alternative attack vectors to bypass defenses.

It appears now that criminals have rediscovered TCP reflection attacks almost 20 years later and the results have been surprising. The notion that we live in a perfect world where devices will only re-transmit packets five times has been shattered. In a research paper published in 2014, Hell of a Handshake, authors detail how attackers can abuse the TCP protocol to launch reflective TCP floods that generate amplification due to packet re-transmission.

[You may also like: What to Do When You Are Under DDoS Attack]

Networks and devices have changed dramatically over the last two decades. The evolution of the cloud has transformed the way we conduct business and IoT devices have changed the way we live life. As a result, the attack landscape has grown.

Defending Against TCP Reflection Attacks

The core issue with a TCP reflection attack is defending against it. The technique abuses a fundamental protocol to attack a primary victim and cause collateral damage. It’s also incredibly easy for an attacker to generate a list of SYN packet reflectors and research what ports will result in the large amplification in re-transmission of packets. 

The best way to mitigate SYN floods is with SYN protection or by reporting and blacklisting the attacker’s IPs. The problem is, blacklisting becomes another factor in the denial of service attack since the criminal is misrepresenting legitimate IP addresses. Not only do the targeted victims, who are often large and well protected corporations, have to deal with floods of TCP SYN-ACK traffic, but randomly selected reflectors ranging from smaller businesses to homeowners, have to process the spoofed SYN requests and potential legitimate replies from the target of the attack. Those that are unprepared for these kinds of spikes in traffic suffer from secondary outages.

We expect this attack vector to be included in the DDoS landscape going forward. Expect to see TCP amplification used in parallel with UDP amplification as part of a multi-vector campaign designed to defeat mitigation defenses.   

Download Radware’s “Hackers Almanac” to learn more.

Download Now

Daniel Smith

Daniel is the Head of Research for Radware’s Threat Intelligence division. He helps produce actionable intelligence to protect against botnet-related threats by working behind the scenes to identify network and application-based vulnerabilities. Daniel brings over ten years of experience to the Radware Threat Intelligence division. Before joining, Daniel was a member of Radware’s Emergency Response Team (ERT-SOC), where he applied his unique expertise and intimate knowledge of threat actors’ tactics, techniques, and procedures to help develop signatures and mitigate attacks proactively for customers.

Contact Radware Sales

Our experts will answer your questions, assess your needs, and help you understand which products are best for your business.

Already a Customer?

We’re ready to help, whether you need support, additional services, or answers to your questions about our products and solutions.

Get Answers Now from KnowledgeBase
Get Free Online Product Training
Engage with Radware Technical Support
Join the Radware Customer Program


An Online Encyclopedia Of Cyberattack and Cybersecurity Terms

What is WAF?
What is DDoS?
Bot Detection
ARP Spoofing

Get Social

Connect with experts and join the conversation about Radware technologies.

Security Research Center