312-50 Question 198
Single answer▪ Sniffing Technique: DNS PoisoningDuring an internal security assessment, you are connected to the same switched LAN as several employee workstations. The organization uses an internal DNS server for name resolution, but some users report that when they browse to the company VPN portal by name, they are intermittently redirected to a fake login page hosted on another internal system. You suspect DNS cache poisoning or spoofed DNS replies on the local segment. Which action would most directly help you confirm that the redirection is caused by forged DNS responses rather than a compromised web server or browser issue?
- A
Capture traffic and compare DNS transaction IDs, source IP addresses, and answer records to verify whether multiple DNS replies are being received for the same query, including one from an unauthorized host
- B
Run a vulnerability scan against the VPN portal and verify whether the web server is missing security patches
- C
Clear the browser cache on an affected workstation and check whether the fake login page still loads
- D
Review the workstation's hosts file to determine whether the VPN portal name was statically mapped to a malicious IP address
Show answer and explanation
Correct answer: A
Explanation
The best answer is to capture and analyze DNS traffic for evidence of spoofed replies. In practical CEH-style scenarios, DNS poisoning on a local network often involves an attacker racing the legitimate DNS server to answer a victim's query with a forged response pointing to a malicious IP. Evidence includes duplicate responses to the same query, replies from unauthorized systems, suspicious TTL values, and mismatched source IPs compared with the organization's approved DNS server. This approach is aligned with standard packet analysis practices using tools such as Wireshark or tcpdump.
By contrast, scanning the web server focuses on application/server compromise rather than name-resolution abuse. Clearing browser cache can help with general troubleshooting but does not isolate DNS as the root cause. Reviewing the hosts file is useful to rule out local tampering, yet it does not prove network-based DNS poisoning. Relevant best practices include monitoring for unauthorized DNS responders, using DNSSEC where applicable to validate DNS data authenticity, restricting recursive resolution, and segmenting or protecting local networks against man-in-the-middle techniques such as ARP spoofing that are often used to facilitate DNS spoofing.
- A. Correct.
Correct. DNS poisoning/spoofing on a LAN is commonly confirmed by packet capture showing a DNS query followed by competing or unexpected replies, often from an IP address that is not the legitimate DNS server. Examining transaction IDs, queried names, response timing, source addresses, and returned resource records helps distinguish a forged reply from a legitimate one. This directly tests the DNS layer, which is where poisoning occurs.
- B. Incorrect.
Incorrect. A vulnerable or unpatched VPN web server could explain compromise of the site itself, but it does not directly validate DNS poisoning. If users are being redirected to a fake page because the hostname resolves to a malicious IP, the key evidence will be in DNS traffic, not only in the target server's patch state.
- C. Incorrect.
Incorrect. Clearing browser cache may help rule out a locally cached page, but it does not directly confirm forged DNS responses. A user could still be redirected after cache clearing for many reasons, including hosts file tampering, proxy abuse, or actual DNS spoofing. This step is weaker and less conclusive than packet-level DNS analysis.
- D. Incorrect.
Incorrect. Checking the hosts file is a reasonable troubleshooting step because static name resolution can mimic DNS poisoning symptoms. However, the scenario asks what would most directly confirm forged DNS responses. A malicious hosts file entry indicates local tampering, not necessarily DNS poisoning on the network.