TCP Reflection: An Attack Disguised as a Handshake

TCP Reflection is often part of multi-vector DDoS attacks. Threats of this type are particularly dangerous: at the packet level, they resemble legitimate traffic while generating a high load on infrastructure in terms of packet rate. In this article, we break down the mechanisms attackers use and how to build effective protection.

What Is TCP Reflection?

TCP Reflection is a class of DDoS attacks in which attackers exploit the mechanics of the TCP three-way handshake to turn legitimate servers into unwitting participants in an attack. Instead of sending malicious traffic directly, they force thousands of third-party nodes — known as reflectors — to generate large volumes of TCP packets toward the victim. This creates a large volume of reflected traffic.

TCP Reflection operates at the transport layer (L4) of the OSI model and is a subtype of reflection-based DDoS attacks. Attackers use this method to generate both volumetric and protocol-level attacks. The primary target is not bandwidth (Gbps), but packet processing performance (PPS) and TCP stack resources.

How the Attack Works

TCP Reflection consists of four main stages:

1. Source IP Spoofing

The attacker generates TCP segments with the SYN flag — standard connection requests. However, instead of their own IP address, they insert the victim’s IP address in the Source IP field.

Technically, these are “TCP segments with the SYN flag,” since a packet belongs to the network layer (IP), not the transport layer (TCP). However, for simplicity, we will use the common term “packet.”

These forged SYN packets are sent to numerous legitimate internet-facing servers with open ports: web servers, cryptographic gateways, mail servers, and other nodes that accept incoming TCP connections. Each of them becomes a potential reflector.

2. Reflector Response

The reflector server treats the incoming SYN packet as the start of a legitimate TCP connection — at the transport layer, it looks identical to a normal client request.

Following the standard three-way handshake, the reflector generates a SYN+ACK response and sends it to the IP address specified in the Source IP field — that is, the victim’s address.

The victim receives SYN+ACK packets it never requested. Since no ACK response follows, the connection remains incomplete.

3. Amplification via Retransmissions

This is where the key amplification mechanism comes into play. If no ACK is received within the timeout period, the reflector does not immediately drop the connection. Instead, it retransmits SYN+ACK packets according to the tcp_synack_retries parameter.

For example, in Linux, the default is 5 retries, with a maximum of 255. Each retransmission adds another packet sent to the victim. 

As a result, a single spoofed SYN packet can generate 5–6 SYN+ACK packets from one reflector.

4. Scaling

Attackers involve thousands or tens of thousands of reflectors, amplifying the effect. For example, if 10,000 reflectors retransmit a spoofed SYN request five times, this results in 60,000 SYN+ACK packets directed at the victim — a powerful stream capable of overwhelming network equipment or the TCP/IP stack.

Why TCP Reflection Is So Dangerous

These attacks are difficult to detect for two reasons:

1. The main impact comes from packet rate (PPS), not bandwidth (bps). The attack targets packet processing capacity (control plane / data plane), not channel saturation. Many monitoring systems rely on traffic volume thresholds, meaning that high-PPS but low-bandwidth attacks may go undetected despite degrading system performance.
2. Legitimate sources are used. Attackers leverage real servers that respond correctly to spoofed SYN requests. As a result, the victim receives SYN+ACK packets from valid IP addresses of legitimate public services. From a traffic perspective, these packets are indistinguishable from legitimate responses, making signature- or reputation-based filtering ineffective.

The only reliable way to distinguish legitimate SYN+ACK packets from reflected ones is to correlate them with outgoing traffic. If the protected system previously sent a SYN request, the SYN+ACK is valid. If not, it indicates an attack.

This requires analyzing both inbound and outbound traffic — a symmetric filtering approach. In asymmetric setups, where only incoming traffic is filtered, it becomes much harder to differentiate between legitimate and malicious SYN+ACK packets.

Read more: Symmetric and Asymmetric Filtering of DDoS Attacks

Types of TCP Reflection Attacks

TCP SYN-ACK Reflection

The classic variant described above. Attackers send spoofed SYN segments to many servers, which respond with SYN+ACK packets and retransmit them multiple times.

TCP Middlebox Reflection

A more advanced variant where reflectors are intermediate network devices (middleboxes), such as firewalls, DPI systems, or content filtering systems. These devices may respond to certain TCP segments in non-standard ways — for example, generating block pages, HTTP redirects, or RST packets.

How attacks occur:

1. The attacker sends TCP segments with HTTP headers targeting restricted resources.
2. The middlebox intercepts the request and generates its own response (HTML block page, JSON error, redirect headers, etc.).
3. The response is sent to the victim’s IP address.

This type of attack is especially dangerous because the response size can exceed the request by tens or hundreds of times. Amplification factors of up to 65× have been observed, comparable to UDP amplification attacks.

TCP ACK Reflection

The attacker generates a large number of ACK segments with spoofed source IP addresses and sends them to servers or network devices. The TCP stack processes ACK packets as potentially valid, attempting to match them with existing connections. Under high load, this consumes significant resources and may lead to exhaustion of system capacity.

Notable Attacks and Side Effects

One of the first major waves of TCP Reflection attacks was observed in Scandinavia and Southern Europe in 2019. Attackers used tens of thousands of open servers as reflectors, heavily impacting financial and telecom organizations.

Since 2022, TCP Middlebox Reflection attacks have emerged in practice, after previously being only theoretical. Industries affected include banking, tourism, gaming, media, and web hosting.

A notable side effect is that reflector servers themselves experience abnormal load due to numerous incomplete TCP connections. This leads to degraded performance and partial outages, affecting providers and businesses whose infrastructure is unknowingly used in attacks.

Protection Methods

Protecting public TCP services can be straightforward in some cases. If a service only accepts incoming connections and does not initiate outbound ones, blocking incoming SYN+ACK packets (along with UDP traffic) may be sufficient.

However, for ISPs, hosting providers, and complex infrastructures, a comprehensive approach is required. Protection should be implemented across multiple layers.

1. Traffic profiling and segmentation.

Proper segmentation of resources by IP addresses and subnets allows applying tailored filtering policies. For example, web servers can block all protocols except TCP and reject SYN+ACK packets entirely, since they do not initiate outbound connections.

2. Preventing IP spoofing.

Implementing BCP38 recommendations helps prevent IP spoofing. Network edge routers should filter outgoing packets with invalid source IP addresses. 

Technologies like Unicast Reverse Path Forwarding (uRPF) automate this process.

3. Hardening reflectors.

Servers can be configured to reduce amplification:

• Lower the number of SYN+ACK retransmissions;
• Enable SYN cookies;
• Limit incoming SYN requests per IP or subnet at the TCP port level.

4. Configuring middleboxes.

Reduce response sizes and avoid generating large payloads (e.g., full HTML pages). Use minimal responses such as HTTP 301 or 403.

5. Using anti-DDoS solutions.

Modern anti-DDoS systems detect TCP Reflection by analyzing traffic patterns, especially anomalies in PPS and TCP flag distribution. Suspicious traffic is redirected to scrubbing centers, where malicious packets are filtered out.

Why StormWall Effectively Protects Against TCP Reflection

With a symmetric filtering approach, StormWall analyzes both incoming and outgoing traffic. This makes it possible to accurately distinguish legitimate SYN+ACK responses from reflected attack traffic — enabling complete mitigation.

StormWall also offers a proprietary TCP Reflection filtering mechanism. It ensures protection against even the most powerful attacks using intelligent filters and real-time traffic analysis. The solution also works in asymmetric setups, significantly reducing the number of malicious packets reaching protected resources.