What Is a TCP SYN-ACK Flood Attack? | Reflected SYN-ACK Backscatter Explained

A reflected TCP SYN-ACK Flood is a DDoS technique in which an attacker spoofs a victim’s IP address as the source of TCP SYN packets sent to large numbers of third-party servers, causing those uninvolved servers to send their SYN-ACK responses to the victim instead of back to the attacker. The victim receives a flood of unsolicited SYN-ACK packets it never requested, consuming inbound bandwidth and forcing stateful devices to classify traffic that matches no local connection.

TL;DR: The attacker never contacts the victim directly. It sends SYN packets with the victim’s spoofed IP as the source to many public, uninvolved servers (“reflectors”). Each reflector, believing it received a legitimate connection request, replies with a SYN-ACK — but sends it to the spoofed address, meaning the victim’s network. The victim is buried under a volume of SYN-ACK packets from IPs it never contacted, none of which correspond to any connection it initiated. Unlike classic SYN Flood, which exhausts the connection queue, reflected SYN-ACK Flood primarily exhausts inbound bandwidth and stateful-inspection capacity. Mitigation depends on discarding SYN-ACKs that don’t match an outbound SYN the victim actually sent, plus provider-side anti-spoofing filtering (BCP38/uRPF) to reduce the pool of reflectors attackers can abuse.

Last updated: 2026-08-27

How a Reflected TCP SYN-ACK Flood Works

1. The attacker selects a large list of reachable TCP servers on the internet — these become unwitting reflectors. Any server that responds to SYN packets on an open port qualifies.
2. The attacker sends a TCP SYN packet to each reflector’s open port, but sets the source IP address to the victim’s IP instead of its own.
3. Each reflector processes the SYN as a normal connection request, allocates a half-open connection entry, and replies with a SYN-ACK — addressed to the spoofed source, which is the victim.
4. The victim receives a SYN-ACK for a connection it never initiated. Its TCP stack or firewall finds no matching outbound SYN in its state table and classifies the packet as unsolicited/out-of-state.
5. Multiplied across thousands of reflectors and repeated at high frequency, the victim is hit with a large volume of inbound SYN-ACK traffic simultaneously, none of which required the attacker to send any traffic directly to the victim.
6. The reflectors’ own half-open connections eventually time out on their end since the spoofed victim never sends the final ACK — but the damage to the victim happens from the SYN-ACK backscatter itself, not from the reflectors’ internal queue state.

Normal traffic (victim initiates a connection):
Victim ──SYN──▶ Remote server
Victim ◀─SYN-ACK── Remote server   [SYN-ACK matches Victim's own outbound SYN]
Victim ──ACK──▶ Remote server      [Connection established]

Reflected SYN-ACK Flood:
Attacker ──SYN (spoofed src = Victim IP)──▶ Reflector A
Attacker ──SYN (spoofed src = Victim IP)──▶ Reflector B
Attacker ──SYN (spoofed src = Victim IP)──▶ Reflector C
   ... [thousands of reflectors, repeated continuously]

Reflector A ──SYN-ACK──▶ Victim   [Victim never sent this SYN]
Reflector B ──SYN-ACK──▶ Victim   [Victim never sent this SYN]
Reflector C ──SYN-ACK──▶ Victim   [Victim never sent this SYN]
   ... [victim receives SYN-ACK backscatter from every reflector]

Result: Victim's inbound bandwidth and stateful inspection capacity
        are consumed by SYN-ACK packets matching no local connection

Which TCP Flag Attack Is This? Comparison Table

The defining trait of the reflected SYN-ACK Flood is that the victim never sees a single attacker-controlled packet — every packet the victim receives comes from a legitimate, uninvolved third-party server. This is fundamentally different from a direct SYN-ACK flood, in which an attacker (or botnet) sends SYN-ACK packets straight to the victim without any reflector involved; a direct variant mainly stresses the victim’s out-of-state classification logic without amplifying volume through third parties.

Attack Variations

Direct SYN-ACK flood (no reflection). A botnet sends SYN-ACK packets directly to the victim, with no third-party reflectors in the path. This lacks the amplification and IP-spoofing-attribution benefits of the reflected variant but is simpler to execute since it doesn’t depend on finding responsive reflectors.

Reflected SYN-ACK Flood combined with amplification protocols. Attackers sometimes run reflected SYN-ACK floods alongside UDP-based amplification (DNS, NTP) against the same victim to stress both TCP state handling and raw bandwidth simultaneously. See DDoS Attack Types for the amplification category.

Rotating reflector pools. Sophisticated campaigns rotate through large lists of reflectors to avoid any single reflector network detecting and rate-limiting the spoofed SYN traffic it’s unwittingly relaying.

Detection Signals and Telemetry

# Socket summary — reflected SYN-ACK floods typically don't move SYN_RECV
ss -s

# TCP counters — watch for anomalies in received SYN-ACKs without matching outbound SYNs
nstat -az

# Conntrack: SYN-ACK packets with no matching NEW/ESTABLISHED entry are classified INVALID
conntrack -L | grep -i syn_recv
conntrack -S

# nftables rule to count/log unsolicited SYN-ACKs
nft add rule inet filter input tcp flags syn,ack / syn,ack ct state invalid counter log prefix "unsolicited-synack "

# iptables equivalent
iptables -A INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -m conntrack --ctstate INVALID -j LOG --log-prefix "unsolicited-synack "

Flow analysis (NetFlow/IPFIX/sFlow) is particularly effective here: correlate the volume of inbound SYN-ACK packets against the volume of outbound SYN packets your own network generated in the same window. A large, sustained imbalance is the clearest signature of reflected SYN-ACK backscatter.

Mitigation Techniques

Common Mistakes and Fixes

How to Implement on Azion

Azion’s distributed network can filter reflected SYN-ACK traffic before it consumes your origin’s bandwidth or processing capacity:

• DDoS Protection is designed to detect abnormal inbound SYN-ACK volume and other Layer 3/4 reflection patterns at the edge, before traffic reaches your origin.
• Network Shield applies filtering rules that can discard packets not matching any tracked outbound connection.
• Firewall allows custom rules for state-based and rate-based blocking of unsolicited traffic.
• WAAP combines network- and application-layer protection for teams needing broader coverage.

Because Azion can terminate and track TCP state at the edge, unsolicited SYN-ACK backscatter directed at an origin behind Azion is generally filtered before it reaches origin infrastructure. Actual protection depends on your specific configuration; validate behavior against your traffic profile.

Related Resources

• What Is a DDoS Attack?
• DDoS Attack Types
• What Is a SYN Flood Attack?
• What Is DDoS Protection and Mitigation?
• What Is a TCP ACK Flood Attack?
• What Is a TCP Out-of-State Flood Attack?
• What Is a TCP Invalid Packet Attack?

Frequently Asked Questions

What is a reflected TCP SYN-ACK Flood attack? It’s a DDoS technique where an attacker spoofs a victim’s IP address in SYN packets sent to many third-party servers. Those servers respond with SYN-ACK packets addressed to the spoofed IP — the victim — flooding it with unsolicited traffic it never requested.

How is a reflected SYN-ACK Flood different from a SYN Flood? A SYN Flood sends SYN packets directly to the victim, exhausting its connection queue with half-open sessions. A reflected SYN-ACK Flood sends no traffic to the victim directly; it abuses third-party servers as reflectors, and the victim only receives their SYN-ACK responses, which primarily consume bandwidth and stateful-inspection capacity rather than the connection queue.

Does a reflected SYN-ACK Flood always require IP spoofing? Yes, by definition. The attack depends on forging the victim’s IP as the source address in SYN packets sent to reflectors. Without spoofing, the reflectors would send their SYN-ACK responses back to the attacker instead of the victim.

What is the difference between a reflected and a direct SYN-ACK flood? A reflected SYN-ACK Flood uses third-party servers to generate the SYN-ACK traffic that hits the victim, requiring IP spoofing against those reflectors. A direct SYN-ACK flood has a botnet or attacker send SYN-ACK packets straight to the victim with no reflectors involved, which is simpler but doesn’t amplify volume the same way.

How is this different from a TCP ACK Flood? A TCP ACK Flood sends ACK-only packets directly to the victim for non-existent connections, mainly costing CPU on state lookups. A reflected SYN-ACK Flood sends SYN-ACK packets that originate from innocent third-party servers, not the attacker, and mainly costs inbound bandwidth and stateful-inspection capacity at the victim.

Can SYN Cookies stop a reflected SYN-ACK Flood? No. SYN Cookies protect the target’s own SYN backlog queue against SYN Flood. A reflected SYN-ACK Flood doesn’t target the SYN queue at all — the victim never sent a SYN to trigger cookie logic in the first place, since it’s receiving unsolicited SYN-ACKs, not SYN requests.

How do I detect reflected SYN-ACK backscatter? Correlate outbound SYN volume against inbound SYN-ACK volume using flow data (NetFlow/IPFIX/sFlow) or conntrack logs. A large, sustained imbalance — many more inbound SYN-ACKs than outbound SYNs you actually sent — combined with high source-IP diversity on the SYN-ACK traffic is the clearest signal.

Are the servers sending the SYN-ACK flood traffic malicious? No. The reflectors are typically legitimate, uninvolved servers responding normally to what looks like a valid connection request. They are unwitting participants; the malicious act is the attacker’s initial IP-spoofed SYN, not the reflector’s response.

Does BCP38 fully prevent reflected SYN-ACK Flood attacks? No. BCP38 (RFC 2827) filters spoofed traffic leaving a network, but it must be adopted broadly across the internet to be effective — a single organization’s adoption doesn’t stop attackers from spoofing through networks that haven’t implemented it. It reduces the pool of usable reflectors over time rather than eliminating the technique immediately.

Can my own infrastructure be used as a reflector in this type of attack against someone else? Yes, if your servers respond to SYN packets from any source without additional validation, they can be abused as reflectors against a third-party victim. Applying the same anti-spoofing and rate-limiting hygiene recommended for defense also reduces this exposure.

Sources

• IETF. “Transmission Control Protocol.” RFC 793. 1981.
• IETF. “Transmission Control Protocol (TCP) Specification.” RFC 9293. 2022.
• IETF. “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.” RFC 2827 (BCP 38). 2000.
• NIST. “Guide to Intrusion Detection and Prevention Systems.” SP 800-94.
• CISA. “Understanding and Responding to Distributed Denial-of-Service Attacks.”