312-50 Question 276
Select 2▪ Detecting HoneypotsDuring an authorized internal assessment, you identify a host that appears unusually attractive: it has many common ports open, responds quickly to scans, and presents several services that seem intentionally exposed. Before interacting further, you want to determine whether the system is likely a honeypot without causing damage or triggering unnecessary alerts. Which TWO actions would provide the strongest indicators that the host is a honeypot?
- A
Compare the TCP/IP stack behavior, banner consistency, and service fingerprints to see whether multiple services look emulated or inconsistent with the claimed operating system
- B
Send a large volume of malformed packets and repeated exploit attempts to see whether the host crashes or blocks you differently than production systems
- C
Correlate the host's apparent services with normal business context, and check whether the same IP exposes an unrealistic combination of services that would not typically coexist on a real server
- D
Assume it is a real host if Nmap service detection identifies versions for HTTP, SSH, and SMTP without errors
- E
Use latency alone as the deciding factor; a low-latency response generally proves the host is a honeypot
Show answer and explanation
Correct answers: A, C
Explanation
The best answer is to combine technical fingerprint analysis with environmental context. In real assessments, suspected honeypots are often identified by inconsistencies: TCP/IP stack details that do not fit the claimed OS, service banners that do not match actual protocol behavior, or an unrealistic collection of exposed services that does not align with the host's expected business role. These are safer and more defensible indicators than aggressive probing. Tools such as Nmap can assist with OS and service fingerprinting, but results must be interpreted critically because honeypots may emulate responses. This aligns with common reconnaissance best practices: validate via multiple passive and low-impact active indicators, correlate with asset context, and avoid assuming authenticity based on banners alone. Relevant references include Nmap documentation on OS and service/version detection and general best practices in penetration testing methodologies that emphasize cautious enumeration and verification before deeper interaction.
- A. Correct.
Correct. One practical way to detect a honeypot is to look for inconsistencies between the claimed OS, TCP/IP stack characteristics, and the behavior of exposed services. Low- to medium-interaction honeypots often emulate services and can reveal mismatches such as banners that do not align with protocol behavior, TCP options that do not match the advertised platform, or multiple services that fingerprint oddly. This is a standard cautious validation technique during reconnaissance.
- B. Incorrect.
Incorrect. Flooding a suspected system with malformed traffic or exploit attempts is not an appropriate first step and may exceed the scope of safe reconnaissance, create unnecessary risk, or trigger defensive controls. It also does not reliably distinguish a honeypot from a hardened production host. In a CEH context, detection should favor careful fingerprinting and analysis over aggressive interaction.
- C. Correct.
Correct. Honeypots are often designed to appear attractive by exposing numerous commonly targeted services. A host advertising an unrealistic mix of services with little business justification, especially in an internal environment where asset roles are usually predictable, is a strong indicator. Contextual analysis is important because real servers usually have a role-driven service profile, while honeypots may expose extra services to lure attackers.
- D. Incorrect.
Incorrect. Nmap version detection returning plausible results does not prove the host is real. Many honeypots are specifically designed to answer probes in a convincing way, and some can emulate banners or enough protocol behavior to satisfy basic scanning. A candidate should avoid equating successful fingerprinting with authenticity.
- E. Incorrect.
Incorrect. Latency by itself is not a reliable indicator. A honeypot may respond quickly because it is lightweight or local, but a legitimate host can also have very low latency. Likewise, network distance, virtualization, load, and routing all affect response time. Latency can support other observations, but it should not be used as the sole deciding factor.