312-50 Question 278
Single answer▪ Detecting HoneypotsDuring an authorized external assessment, you discover a host in the DMZ that appears unusually attractive: it exposes SSH, HTTP, HTTPS, SMTP, and several uncommon high ports, and every probed service responds immediately with generic banners. A TCP/IP fingerprinting scan shows inconsistent OS characteristics across ports, and the web application returns identical error pages regardless of malformed input. You want to determine whether this system is likely a honeypot without performing disruptive exploitation. Which action would provide the strongest additional evidence that the host is a honeypot?
- A
Correlate TCP/IP stack behavior and service fingerprints across multiple ports, looking for mismatched or emulated characteristics that do not align with a single real operating system or application stack
- B
Assume the host is a production load balancer because it has many open ports and therefore should not be tested further
- C
Run a password spraying attack against SSH and SMTP to see whether the system triggers account lockouts faster than normal
- D
Send a large volume of fragmented packets to determine whether the host crashes or rate-limits differently from other DMZ systems
Show answer and explanation
Correct answer: A
Explanation
In real engagements, suspected honeypots are often identified through inconsistencies rather than a single definitive indicator. Useful signs include unrealistic combinations of exposed services, identical or overly generic banners, uniform error handling, low interaction depth, and mismatches between TCP/IP fingerprinting results and claimed application identities. Correlating Nmap service/version detection and OS fingerprinting across ports is especially practical because honeypots frequently emulate services imperfectly or present artifacts inconsistent with a genuine host. This aligns with standard reconnaissance methodology described in common penetration testing practice and tools documentation such as Nmap's service/version detection and OS detection guidance. The key CEH takeaway is to rely on careful enumeration and behavioral correlation rather than disruptive verification methods.
- A. Correct.
Correct. One of the most reliable non-disruptive ways to identify a honeypot is to compare low-level network stack behavior with advertised services and banners. Honeypots and service emulators often present inconsistencies: for example, Nmap OS detection traits may suggest one platform while application banners or protocol behavior resemble another, or different ports may appear to be hosted by incompatible stacks. This approach is commonly used in practice because it gathers corroborating evidence without crossing into destructive testing.
- B. Incorrect.
Incorrect. A host with many open ports is not, by itself, evidence that it is a load balancer or a legitimate production system. In fact, exposing numerous interesting services is a common trait of honeypots designed to attract attackers. The misconception here is equating 'many ports' with 'infrastructure device' without validating behavior, fingerprints, or architecture.
- C. Incorrect.
Incorrect. Password spraying is intrusive, may violate rules of engagement, and is not an appropriate first step for honeypot detection. It also tests authentication controls rather than whether the host is a decoy. A defender may intentionally configure aggressive lockout or alerting on both real systems and honeypots, so any result would be ambiguous and potentially disruptive.
- D. Incorrect.
Incorrect. Sending high volumes of fragmented packets is a stress or evasion technique, not a careful validation method for honeypot detection. It risks causing denial-of-service conditions and generally exceeds what is necessary when the goal is simply to determine whether the host is likely emulated or instrumented. CEH-style best practice favors passive or minimally invasive enumeration before any aggressive action.