312-50 Question 235
Single answer▪ DDoS Case StudyA financial services company asks an ethical hacker to review a recent denial-of-service incident as part of a post-attack case study. During the outage, the public web portal became unreachable, while internal systems remained operational. NetFlow and firewall logs showed tens of thousands of requests per second coming from geographically distributed IP addresses. Most requests completed a valid TCP three-way handshake and then repeatedly requested a CPU-intensive search endpoint. The security team initially suspected a SYN flood, but packet captures showed the application server was spending most of its time processing legitimate-looking HTTP requests rather than waiting on half-open connections. Which attack type best explains this incident?
- A
A distributed HTTP GET flood targeting an expensive application resource
- B
A classic SYN flood exhausting the server's backlog queue
- C
A Smurf attack using ICMP echo requests to a broadcast address
- D
A reflected DNS amplification attack saturating the victim's bandwidth
Show answer and explanation
Correct answer: A
Explanation
This is a classic DDoS case study distinction between volumetric/protocol attacks and application-layer attacks. The deciding evidence is that requests came from many distributed IPs, completed legitimate TCP handshakes, and targeted a costly HTTP endpoint, causing server-side processing strain. That aligns with an HTTP GET flood or, more broadly, an application-layer DDoS attack. By contrast, a SYN flood would leave many half-open connections, and reflection/amplification attacks such as DNS amplification or Smurf attacks primarily aim to overwhelm bandwidth or network edge capacity. In real incident analysis, responders should correlate packet captures, NetFlow, web server logs, and application performance metrics to determine whether the bottleneck is bandwidth, connection state, or application compute. This approach is consistent with common DDoS analysis guidance from sources such as CISA, OWASP application-layer DoS guidance, and vendor incident response playbooks that differentiate Layer 3/4 floods from Layer 7 resource exhaustion.
- A. Correct.
Correct. The scenario describes a distributed attack using many source IPs, valid TCP handshakes, and repeated requests to a resource-intensive web function. That pattern is consistent with an HTTP GET flood at Layer 7, where attackers try to exhaust application or server resources rather than simply consume network bandwidth or TCP state tables. The clue that the server is busy processing requests instead of holding half-open connections strongly supports this answer.
- B. Incorrect.
Incorrect. A SYN flood typically causes many half-open TCP connections and backlog exhaustion because the attacker sends SYN packets without completing the handshake. In this case, the logs explicitly state that the TCP three-way handshake was completed and that the server load came from processing application requests. That makes a SYN flood an understandable but incorrect initial assumption.
- C. Incorrect.
Incorrect. A Smurf attack is an older ICMP-based amplification technique in which spoofed ICMP echo requests are sent to a broadcast address so many hosts reply to the victim. The scenario instead shows completed TCP sessions and repeated HTTP requests to a specific endpoint, which does not match ICMP broadcast amplification behavior.
- D. Incorrect.
Incorrect. DNS amplification is a reflected volumetric DDoS attack that generally floods the victim with large UDP responses to consume bandwidth or overwhelm edge devices. While it can cause service disruption, the scenario specifically highlights valid TCP handshakes and CPU-intensive HTTP processing on the application server, indicating an application-layer flood rather than a reflection/amplification event.