312-50 Question 277
Single answer▪ Detecting HoneypotsDuring an authorized internal penetration test, you identify a host that appears to expose several common services, including SSH, HTTP, and SMTP. Banner grabbing shows generic responses, and every tested TCP port from 1-1000 appears open but returns nearly identical behavior. The client warned that deception technologies may be deployed and asked you to avoid wasting time on decoy systems. Which action would be the BEST next step to help determine whether the host is a honeypot?
- A
Perform TCP/IP stack fingerprinting and analyze service interaction consistency across ports to look for emulated behavior
- B
Assume the host is legitimate because multiple well-known services are present and continue exploitation attempts
- C
Run a UDP flood against the host and see whether it crashes like a real production server
- D
Trust the service banners because honeypots typically cannot mimic standard daemon responses
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use deeper fingerprinting and behavioral analysis rather than relying on banners or aggressive traffic. In real assessments, honeypots often reveal themselves through inconsistencies: many ports appear open, application responses are overly generic, protocol handling is incomplete, or the claimed services do not align with OS-level TCP/IP characteristics. This approach is consistent with standard penetration-testing methodology: verify the target through layered enumeration, correlate network stack fingerprints with application behavior, and avoid destructive actions unless explicitly authorized. Tools and techniques commonly used in practice include Nmap service/version detection and OS fingerprinting, manual banner and protocol validation, and comparing response consistency across services. Best practice guidance from Nmap documentation and general penetration-testing methodology supports using fingerprint correlation and protocol-specific interaction to identify deceptive or emulated systems.
- A. Correct.
Correct. A practical way to identify a likely honeypot is to compare TCP/IP stack characteristics and the realism of service interactions. Low- or medium-interaction honeypots often expose many ports with shallow, repetitive, or inconsistent responses that do not fully match the claimed services or the underlying operating system fingerprint. Examining TTL, window size, TCP options, and how applications respond to protocol-specific requests can reveal emulation artifacts. This is a safer and more professional validation step during an authorized assessment.
- B. Incorrect.
Incorrect. The presence of multiple common services does not prove legitimacy. In fact, exposing many attractive services is a common deception tactic used by honeypots to entice attackers. Continuing exploitation attempts without validating the target may waste testing time and increase the chance of triggering monitoring or deception workflows.
- C. Incorrect.
Incorrect. Launching a UDP flood is not an appropriate honeypot detection technique in a professional engagement. It is disruptive, could violate rules of engagement, and a system's failure or resilience under denial-of-service traffic does not reliably distinguish a honeypot from a production host. CEH-aligned practice emphasizes controlled enumeration over destructive testing.
- D. Incorrect.
Incorrect. Service banners are easy to fake or proxy, and many honeypots are specifically designed to imitate standard daemon responses well enough to mislead superficial checks. Relying on banners alone is a common mistake; deeper protocol validation and fingerprint correlation are more reliable.