CEH Network and Web Application Attacks Practice Question
You are the lead security engineer for a financial technology company that hosts a critical web application on three load-balanced servers behind a reverse proxy. The application uses a REST API to process transactions. Recently, the company has experienced intermittent service outages during peak hours. Upon reviewing logs, you find that the reverse proxy is returning HTTP 503 errors for legitimate API requests, and the application servers show high CPU usage but normal memory. The network team reports no bandwidth issues. The application team claims no code changes were made. You suspect a specific type of attack is causing the outages. Which action should you take first to confirm the attack type?
⚠ Common exam trap
The trap here is that candidates often jump to blocking IPs (Option A) or scaling horizontally (Option C) as immediate fixes, but the CEH exam emphasizes first confirming the attack vector through log analysis rather than taking reactive or misdirected actions.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Analyze the incoming request patterns in the reverse proxy logs to identify if there is a high volume of requests to a specific API endpoint.
The symptoms—HTTP 503 errors, high CPU usage on application servers, normal memory, and no bandwidth issues—strongly suggest a Layer 7 DDoS attack, specifically an HTTP flood targeting a resource-intensive API endpoint. By analyzing reverse proxy logs for a high volume of requests to a specific endpoint, you can confirm the attack type (e.g., a slow loris or GET flood) before taking mitigation steps. This aligns with the CEH methodology of first identifying the attack vector through log analysis.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Configure the firewall to block all incoming traffic from the IPs that appear most frequently in logs.
Why it's wrong here
While blocking frequently appearing IPs might seem like a direct response, it is a reactive measure that fails to confirm the specific attack type causing high CPU and 503 errors. Such an approach risks blocking legitimate users if the attack employs IP spoofing or a large, distributed botnet. More critically, it does not provide insight into the attack's nature (e.g., Layer 7 vs. Layer 4 DDoS, or other attack vectors), which is essential for developing a precise and effective mitigation strategy.
- ✓
Analyze the incoming request patterns in the reverse proxy logs to identify if there is a high volume of requests to a specific API endpoint.
Why this is correct
Analyzing reverse proxy logs (e.g., NGINX, HAProxy) is crucial because they capture detailed information about incoming HTTP/HTTPS requests, including source IPs, user agents, request methods, and target URLs/API endpoints. Identifying a sudden, high volume of requests directed at a specific API endpoint, especially with diverse source IPs or suspicious user agents, strongly indicates a Layer 7 (application-layer) DDoS attack. This diagnostic step directly confirms the attack type and pinpoints the targeted service, enabling highly focused and effective countermeasures.
- ✗
Increase the number of application servers to handle the load.
Why it's wrong here
Increasing the number of application servers might temporarily alleviate the symptoms of high CPU utilization and 503 errors by distributing the load across more resources. However, this is a reactive scaling measure, not a diagnostic one. It consumes additional resources without identifying the root cause or specific nature of the attack (e.g., whether it's a volumetric DDoS, resource exhaustion, or a legitimate traffic surge). Without understanding the attack type, scaling can be inefficient, costly, and ultimately overwhelmed by a persistent, targeted attack.
- ✗
Run a SQL injection scanner on the application.
Why it's wrong here
SQL injection is a code injection technique primarily used to exploit vulnerabilities in data-driven applications, typically aiming for data exfiltration, manipulation, or unauthorized access to databases. While successful SQL injection can lead to severe data breaches, it does not directly manifest as widespread high CPU utilization across servers or 503 "Service Unavailable" errors, which are indicative of resource exhaustion or service overload. Running a scanner for this vulnerability is irrelevant to diagnosing the observed symptoms and diverts resources from the actual problem.
Go deeper
Related to this question
Learn chapter
Vulnerability Analysis
Key term
Covering Tracks
Covering tracks is the process attackers use to hide their activity and remove evidence of a security breach after gaining unauthorized access to a system.
Key term
Nmap Scanning
Nmap scanning is a method used to discover devices running on a network and find open ports, services, and security weaknesses.
About these practice questions
This CEH question is part of Courseiva's 870-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CEH practice question is part of Courseiva's free EC-Council certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CEH exam.