Honeypots and deception technologies are proactive security controls that lure attackers away from real assets while gathering threat intelligence. This chapter covers how honeypots work, their types (low-interaction, high-interaction, honeyfiles, honeytokens), deployment strategies, and how they integrate with SIEM and SOAR. On the CS0-003 exam, deception technologies appear in about 5-8% of questions, typically in Security Operations (Domain 1) and Threat Intelligence (Domain 4). You must understand when to deploy a honeypot versus a honeynet, how to interpret deception data, and the legal considerations of entrapment.
Jump to a section
A honeypot is like a moth trap deployed in a vineyard. The trap contains a pheromone lure that mimics the scent of a female moth, attracting male moths. When a moth enters, it gets stuck on a sticky pad, allowing the vintner to identify the species, count the population, and monitor when pests are active. The trap is placed away from the valuable grapevines, so any damage is isolated to the trap itself. Similarly, a honeypot in a network uses fake services, data, or credentials to lure attackers. It sits on a separate VLAN or subnet, isolated from production assets. When an attacker interacts with the honeypot, the security team logs every keystroke, command, and tool used—without risking real systems. Just as the vintner learns which pests are present and their behavior patterns, the blue team learns the attacker's tactics, techniques, and procedures (TTPs). The honeypot also acts as an early warning system: if a moth is caught, the vintner knows the pest pressure is high and can take preventive action. In networking terms, a honeypot triggers alerts when any traffic hits it because legitimate traffic should never touch it. This zero-noise property makes even a single connection a high-fidelity indicator of compromise.
What Is a Honeypot and Why Does It Exist?
A honeypot is a decoy system designed to appear as a legitimate target for attackers. Its primary purposes are: (1) early detection of unauthorized activity, (2) collection of threat intelligence on attacker TTPs, (3) diversion of attackers away from production systems, and (4) research on new vulnerabilities and exploits. Honeypots exist because traditional security controls like firewalls and IDS/IPS generate high volumes of alerts, many false positives. A honeypot has zero production value—any traffic to it is inherently suspicious, so alerts have near-zero false positives. This makes honeypots an exceptionally high-fidelity detection mechanism.
How Honeypots Work: Internal Mechanism
A honeypot emulates services, operating systems, or applications that an attacker would target. It listens on TCP/UDP ports that are commonly scanned, such as:
TCP 22 (SSH)
TCP 23 (Telnet)
TCP 80/443 (HTTP/HTTPS)
TCP 445 (SMB)
TCP 3389 (RDP)
When an attacker connects, the honeypot logs the connection source IP, timestamp, protocol, and payload. Low-interaction honeypots simulate only the initial handshake and a limited set of commands. High-interaction honeypots run full operating systems and applications, allowing the attacker to execute arbitrary code while being monitored.
Packet-level flow for a low-interaction SSH honeypot: 1. Attacker sends TCP SYN to port 22 on honeypot IP. 2. Honeypot responds with SYN-ACK, completing the three-way handshake. 3. Attacker sends SSH banner (e.g., "SSH-2.0-OpenSSH_7.4"). 4. Honeypot responds with a fake banner (e.g., "SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu1"). 5. Attacker attempts authentication with credentials like "root:admin". 6. Honeypot logs the credentials and sends a fake "Permission denied" message. 7. Attacker may try multiple password combinations; all are logged. 8. Honeypot eventually closes the connection after a configurable timeout (default 60 seconds).
Key Components, Values, Defaults, and Timers
Low-interaction honeypot: Emulates services at the protocol level without a full OS. Example: Honeyd, Dionaea. Default timeout per connection: 30-120 seconds.
High-interaction honeypot: Full OS or VM with real services. Example: Sebek, Argos. No default timeout; attacker can stay indefinitely, but network captures are rotated every 24 hours.
Honeytoken: A fake data object (e.g., database record, API key, file) that triggers an alert when accessed. Example: Canary tokens.
Honeyfile: A decoy file with a enticing name (e.g., "passwords.xlsx") placed on a file share. When opened, it phones home to a SIEM.
Honeynet: A network of honeypots, often with a honeywall that controls inbound/outbound traffic to prevent the honeypot from being used to attack others.
Deception grid: A commercial platform that deploys and manages hundreds of honeypots across the enterprise (e.g., Attivo Networks, Illusive Networks).
Default values in popular honeypot software (Cowrie):
- Listen ports: 22 (SSH), 23 (Telnet)
- Log file location: /var/log/cowrie/cowrie.log
- Max attempts before disconnect: 10
- Session timeout: 300 seconds
- Download limit for files: 1 MB (to prevent filling disk)
Configuration and Verification Commands
Deploying a Cowrie honeypot (SSH/Telnet):
# Install dependencies
sudo apt-get update && sudo apt-get install git python3-virtualenv python3-pip
# Clone Cowrie
git clone https://github.com/cowrie/cowrie.git
cd cowrie
# Set up virtual environment
virtualenv --python=python3 cowrie-env
source cowrie-env/bin/activate
pip install -r requirements.txt
# Configure
cp cowrie.cfg.dist cowrie.cfg
# Edit cowrie.cfg to set hostname, listen ports, etc.
vim cowrie.cfg
# Start honeypot
bin/cowrie startVerification commands:
# Check if honeypot is listening
netstat -tulpn | grep -E ':(22|23)'
# View logs in real time
tail -f /var/log/cowrie/cowrie.log
# Check for successful connections
grep 'login attempt' /var/log/cowrie/cowrie.logDeploying a honeyfile using Canarytokens: 1. Go to canarytokens.org. 2. Select "Web Bug / URL Token" or "DNS Token". 3. Enter your email for alert notification. 4. Download the token (e.g., a fake PDF file). 5. Place the file on a file share (e.g., SMB share). 6. When anyone opens the file, a DNS or HTTP request is sent to the Canary server, which emails you.
Interaction with Related Technologies
Honeypots integrate with: - SIEM: Honeypot logs are forwarded via syslog to SIEM (e.g., Splunk, ELK). Alerts are generated for any connection to honeypot IPs. - SOAR: When a honeypot alert fires, SOAR can automatically block the source IP on the firewall (e.g., via REST API to pfSense or iptables). - Threat intelligence platforms: Attack data (IPs, credentials, malware samples) from honeypots can be fed into TIPs to enrich threat intel. - Firewalls and IPS: Deception feeds can update blocklists automatically.
Types of Honeypots by Interaction Level
Low-interaction: Emulates only a few services. Low risk, low maintenance, but limited data. Example: Honeyd.
Medium-interaction: Simulates more complex protocols (e.g., SSH shell with fake file system). Example: Cowrie.
High-interaction: Full OS. High risk (attacker may use it to attack others), high maintenance, but captures full TTPs. Example: Sebek.
Types of Honeypots by Purpose
Research honeypot: Used to study attacker behavior. Usually high-interaction, deployed by universities or security vendors.
Production honeypot: Used to detect attacks in a live enterprise. Low- or medium-interaction, easy to maintain.
Legal and Ethical Considerations
Entrapment: A honeypot does not entrap because it does not induce someone to commit a crime they were not already predisposed to commit. The attacker actively scans and connects.
Privacy: In some jurisdictions, capturing attacker traffic may violate wiretap laws. Consult legal counsel.
Liability: If a high-interaction honeypot is compromised and used to attack third parties, the owner may be partially liable. Use honeywalls to restrict outbound traffic.
Detection Evasion by Attackers
Sophisticated attackers may detect honeypots by:
Checking for default banners (e.g., Cowrie's default SSH banner is unique).
Sending unexpected commands (e.g., SHOW on a MySQL honeypot).
Looking for delays or unrealistic responses.
Checking for known honeypot IP ranges or reverse DNS.
To counter this, use realistic banners, patch emulated services, and deploy honeypots on IPs that blend in with production subnets.
Plan Honeypot Deployment Strategy
Identify the network segments where attackers are likely to pivot (e.g., DMZ, internal VLANs, cloud subnets). Choose the honeypot type based on risk tolerance: low-interaction for production, high-interaction for research. Determine whether to use a single honeypot or a honeynet. Define the IP address range—honeypots should be on IPs that are not used by any legitimate service to avoid accidental access. Document the deception plan, including which services to emulate (e.g., SSH, RDP, SMB) and what fake data to include (e.g., fake credit card numbers, credentials).
Deploy Honeypot Software
Install the honeypot software on a dedicated VM or container. For low-interaction, use Cowrie (SSH/Telnet), Dionaea (SMB, HTTP, FTP), or Honeyd (multiple protocols). For high-interaction, use a full OS with Sebek kernel module. Configure the honeypot to log to a remote syslog server for centralized monitoring. Set up outbound traffic restrictions using iptables or a honeywall to prevent the honeypot from being used as a launchpad. For example, allow only DNS and HTTP outbound to specific IPs for updates. Verify the honeypot is listening on the intended ports with netstat.
Integrate with SIEM and Alerting
Configure the honeypot to forward logs to the SIEM (e.g., Splunk, Elasticsearch). Create correlation rules that trigger alerts for any connection to honeypot IPs—since no legitimate traffic should ever touch them. Set severity to high or critical. Integrate with SOAR for automated response: e.g., block the attacker IP on the firewall for 24 hours. Test the integration by connecting to the honeypot from a test machine and verifying the alert appears in the SIEM dashboard within 30 seconds.
Deploy Honeytokens and Honeyfiles
Create honeytokens such as fake API keys, database records, or credentials that appear real. Place them in locations where attackers would look (e.g., a GitHub repo, a config file on a web server). Use canary tokens that generate alerts when accessed. Deploy honeyfiles on file shares with enticing names like "passwords.txt" or "financials.xlsx". Configure the honeyfile to execute a script that sends a DNS query to a monitoring server when opened. This detects ransomware or lateral movement that accesses file shares.
Monitor, Analyze, and Refine
Regularly review honeypot logs to identify attacker TTPs. Extract indicators of compromise (IOCs) such as IP addresses, malware hashes, and command patterns. Feed IOCs into the threat intelligence platform and update firewall blocklists. Refine the honeypot configuration based on observed attacks: add new services, change banners, or adjust timeout values. Rotate honeyfiles and tokens periodically to avoid detection. Conduct quarterly reviews of the deception strategy to ensure it aligns with the current threat landscape.
In a large financial services firm, the security team deployed a honeynet across three data centers and two cloud VPCs. They used Cowrie for SSH/Telnet and Dionaea for SMB and HTTP. Each honeypot was placed on a separate VLAN with outbound traffic restricted to only DNS and NTP. The honeypots were integrated with Splunk SIEM via syslog. Within the first week, they detected an attacker who had breached a web server and was scanning internal IPs. The honeypot logged the attacker's IP, the credentials attempted (admin:pass123), and the tools downloaded (a Python reverse shell). The SIEM triggered an alert, and the SOAR automatically blocked the IP on the perimeter firewall. The team also deployed honeyfiles on file shares: a file named "passwords.xlsx" that, when opened, sent a DNS query to a canary server. This caught a ransomware operator who was enumerating shares. The honeyfile alerted before the ransomware encrypted any real files, allowing the team to isolate the infected machine.
In a healthcare organization, a high-interaction honeypot running a fake patient database was deployed to detect insider threats. The honeypot contained fake medical records with honeytokens (fake SSNs). When an employee accessed the database without authorization, the honeytoken triggered an alert. The investigation revealed a nurse who was attempting to sell patient data. The honeypot provided irrefutable evidence of the unauthorized access.
Common misconfigurations include: (1) placing honeypots on the same subnet as production servers, causing accidental traffic; (2) using default banners that attackers recognize (e.g., Cowrie's default SSH banner); (3) failing to restrict outbound traffic, allowing the honeypot to be used for attacks; (4) not integrating with SIEM, so alerts are missed; (5) deploying only one honeypot, missing attacks on other segments. Performance considerations: low-interaction honeypots use minimal CPU/memory (e.g., Cowrie uses ~50 MB RAM per instance). High-interaction honeypots require a full VM with at least 2 GB RAM. In large deployments, use containerization (Docker) to scale.
The CS0-003 exam tests deception technologies under Domain 1.0 (Security Operations), Objective 1.1: "Given a scenario, apply the appropriate security controls to maintain the security posture." Also appears in Domain 4.0 (Threat Intelligence and Threat Hunting), Objective 4.3: "Given a scenario, analyze threat intelligence data."
Common wrong answers and why candidates choose them: 1. "Honeypots are used to trap hackers for prosecution." – Wrong because honeypots are primarily for detection and intelligence, not legal entrapment. Candidates confuse 'detection' with 'apprehension'. 2. "A high-interaction honeypot is safer than a low-interaction honeypot." – Wrong. High-interaction gives attackers more freedom and is riskier. Candidates think 'more features = more control'. 3. "Honeypots should be placed inside the production network to catch internal threats." – Wrong. Honeypots should be on isolated VLANs to avoid false positives. Candidates think 'close to the action' but forget noise. 4. "Honeytokens are fake credentials used to log into production systems." – Wrong. Honeytokens are decoys that trigger alerts when accessed; they are not used for authentication. Candidates confuse them with honeypot credentials.
Specific numbers and terms that appear on the exam: - "Low-interaction honeypot" vs. "High-interaction honeypot" - "Honeynet" (a network of honeypots) - "Honeywall" (controls traffic to/from honeynet) - "Honeytoken" (e.g., fake credit card numbers, fake API keys) - "Canary token" (a type of honeytoken) - "Production honeypot" (used in live environment) - "Research honeypot" (used for study) - "Zero false positives" (honeypot alerts)
Edge cases the exam loves:
What if an attacker uses the honeypot to attack other systems? Answer: Use a honeywall to restrict outbound traffic.
What if a legitimate user accesses the honeypot? Answer: That is a sign of misconfiguration or an insider threat.
What is the difference between a honeypot and a sandbox? Answer: A sandbox is for analyzing malware in isolation; a honeypot is for detecting and deceiving attackers.
How to eliminate wrong answers: Focus on the purpose. If the question asks about detection, choose honeypot. If it asks about analyzing malware without risk, choose sandbox. If it asks about diverting attackers, choose deception technology. Remember that honeypots produce high-fidelity alerts because they have no production value.
A honeypot has zero production value; any traffic to it is suspicious, resulting in near-zero false positive alerts.
Low-interaction honeypots emulate services; high-interaction honeypots run full OSes.
Honeytokens are fake data objects (e.g., credentials, API keys) that trigger alerts when accessed.
Honeyfiles are decoy files placed on file shares to detect unauthorized access or ransomware.
A honeynet is a network of honeypots, often protected by a honeywall that restricts outbound traffic.
Honeypots integrate with SIEM, SOAR, and threat intelligence platforms for automated response.
Legal considerations: honeypots do not constitute entrapment, but consult counsel on wiretap laws.
Common honeypot software: Cowrie (SSH/Telnet), Dionaea (SMB/HTTP), Honeyd (multi-protocol).
These come up on the exam all the time. Here's how to tell them apart.
Low-Interaction Honeypot
Emulates only a few services (e.g., SSH, HTTP).
Low risk of compromise; attacker cannot execute arbitrary code.
Easy to deploy and maintain; minimal resources.
Limited data: logs connection attempts, credentials, and basic commands.
Example: Cowrie, Dionaea.
High-Interaction Honeypot
Runs a full operating system with real services.
High risk; attacker can gain full control and potentially attack others.
Complex to deploy and maintain; requires dedicated VM or physical hardware.
Rich data: captures full attacker TTPs, malware, and lateral movement.
Example: Sebek, Argos.
Honeypot
Purpose: detect and deceive attackers.
Passively waits for attackers to connect.
May allow some interaction to gather intel.
Deployed in production or research networks.
Alerts on any traffic (zero false positives).
Sandbox
Purpose: analyze malware behavior safely.
Actively executes suspicious files or URLs.
Isolated environment; no real interaction with attackers.
Used in malware analysis labs or integrated with email gateways.
Generates detailed behavioral reports.
Mistake
Honeypots are illegal or entrapment.
Correct
Honeypots are legal in most jurisdictions as long as they do not induce criminal activity. Entrapment requires law enforcement to persuade someone to commit a crime; honeypots passively wait for attackers.
Mistake
All honeypots are high-interaction and dangerous.
Correct
Low-interaction honeypots emulate only a few services and pose minimal risk. High-interaction honeypots are riskier but provide richer data.
Mistake
Honeypots can replace firewalls and IDS.
Correct
Honeypots are complementary, not replacements. They detect attacks that bypass other controls but do not prevent them.
Mistake
Honeypots always catch the attacker.
Correct
Sophisticated attackers may detect honeypots and avoid them. Honeypots are one layer of defense, not a silver bullet.
Mistake
Honeytokens are the same as honeypots.
Correct
Honeytokens are specific data objects (e.g., fake credentials) that trigger alerts when used. Honeypots are entire systems. Honeytokens can be placed inside honeypots or anywhere in the network.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A honeypot is a single decoy system, while a honeynet is a network of multiple honeypots, often with a honeywall to control traffic. The honeynet provides a more realistic target environment and can capture more complex attack patterns, such as lateral movement between decoy systems.
Yes, honeypots and honeytokens are effective against insiders. For example, placing a fake file with sensitive-sounding name on a file share can detect an employee who is exfiltrating data. Honeytokens like fake database records can alert when an unauthorized user queries them.
Attackers may detect honeypots by checking for default banners (e.g., Cowrie's default SSH banner), unrealistic response times, missing functionality (e.g., a fake shell that doesn't support certain commands), or known honeypot IP ranges. Using realistic configurations and updating emulated services can reduce detection.
A honeywall is a gateway that sits between a honeynet and the production network. It controls inbound and outbound traffic, logs all connections, and can block outbound attacks from a compromised honeypot. It also prevents the honeypot from being used to attack external systems.
Yes, honeypots can be deployed in cloud VPCs using virtual machines or containers. Cloud providers like AWS and Azure allow you to create decoy instances with public IPs. You can also use honey tokens like fake AWS keys that trigger alerts when used.
Typical default timeout is 60-120 seconds for low-interaction honeypots like Cowrie. This prevents attackers from tying up resources. The timeout is configurable in the honeypot configuration file.
Honeypot logs are sent to SIEM, which triggers an alert. The SOAR platform then executes a playbook, such as blocking the attacker IP on the firewall, adding it to a blocklist, or creating a ticket. This automated response reduces manual effort.
You've just covered Honeypots and Deception Technologies — now see how well it sticks with free CS0-003 practice questions. Full explanations included, no account needed.
Done with this chapter?