Which attack produces a spoofed session by including multiple SYN and ACK packets with RST or FIN, without a full handshake?

Which attack produces a spoofed session by including multiple SYN and ACK packets with RST or FIN, without a full handshake?

• A. Multiple SYN-ACK Spoofed Session Flood Attack
• B. Multiple ACK Spoofed Session Flood Attack
• C. HTTP GET Attack
• D. SYN Flood Attack

Answer: (A)

Spoofed-session floods rely on forged TCP signaling to create the illusion of many active connections without actually completing the three-way handshake. In TCP, a real connection progresses with a SYN from the client, a SYN-ACK from the server, and a final ACK from the client. When an attacker sends multiple SYN and ACK packets that appear to be part of many sessions and couples them with RST or FIN to tear them down, the target spends processing time and memory on these fake connections. Because the handshake is never completed, legitimate connections are harder to establish, and resources get drained. This fits the scenario best because it specifically involves spoofed SYN-ACK activity (and ACK/RST/FIN control signals) to flood the server with fake sessions, rather than simply sending a flood of SYNs (which is a basic SYN flood), focusing on spoofed session state rather than just initial handshake attempts. The HTTP GET attack operates at the application layer, and the other option about ACK spoofing alone describes a different pattern that doesn’t emphasize the SYN-ACK/FIN/RST mix used to create and terminate spoofed sessions.

Spoofed-session floods rely on forged TCP signaling to create the illusion of many active connections without actually completing the three-way handshake. In TCP, a real connection progresses with a SYN from the client, a SYN-ACK from the server, and a final ACK from the client. When an attacker sends multiple SYN and ACK packets that appear to be part of many sessions and couples them with RST or FIN to tear them down, the target spends processing time and memory on these fake connections. Because the handshake is never completed, legitimate connections are harder to establish, and resources get drained.

This fits the scenario best because it specifically involves spoofed SYN-ACK activity (and ACK/RST/FIN control signals) to flood the server with fake sessions, rather than simply sending a flood of SYNs (which is a basic SYN flood), focusing on spoofed session state rather than just initial handshake attempts. The HTTP GET attack operates at the application layer, and the other option about ACK spoofing alone describes a different pattern that doesn’t emphasize the SYN-ACK/FIN/RST mix used to create and terminate spoofed sessions.