What Is a Honeypot and When Does It Actually Make Sense to Deploy One
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Most detection controls are built to identify known attack patterns: a Sigma rule for a specific PowerShell command, a YARA rule for malware hashes, a WAF rule for SQL injection syntax. Attackers evade these by changing their tools and techniques.
Honeypots work differently. They do not require knowing what the attacker is doing: they just require the attacker to interact with something they should not. Because no legitimate user or system has any reason to access a honeypot, any interaction is an alert. The false positive rate is near zero, and the detection works against both known and novel attack techniques.
Types of Honeypots: From Simple Tokens to Network Decoys
1. Canary Tokens (easiest to deploy)
Canary tokens are trap resources that callback to a logging server when accessed. They require no infrastructure and can be deployed in minutes.
Free options at canarytokens.org:
- Web token: A URL that, when fetched, sends an alert with the accessing IP. Embed it in internal documentation, spreadsheets, or config files.
- DNS canary: A hostname that alerts when resolved. Embed it as a fake internal service address in config files: attackers who read your config files will trigger DNS lookups.
- AWS keys: Fake AWS access key ID and secret that alert to AWS CloudTrail when used. Place these in the
~/.aws/credentialsof high-value developer machines or in fake config files. - Word document: A .docx that calls back when opened. Leave it on a file server with an enticing name (
employee-salaries-2026.docx,vpn-credentials.docx). - Custom image: An embedded image in an email or web page that alerts when the image loads.
Deployment strategy: put canary tokens everywhere an attacker would look:
- Fake database.yml or .env file on web servers (fake DB credentials)
- Fake
~/.aws/credentialson EC2 instances (fake AWS keys) - Internal wiki pages: embed a web token in "How to access the admin console"
- Source code repositories: a fake API key in a comment marked
# TODO: remove before push - Network shares: a folder called
backupcontaining a Word document canary
2. Honey Accounts (Active Directory)
Create a fake privileged AD user account with a believable name and role:
# Create a honeypot user that looks like a real admin
New-ADUser -Name "svc-backup-admin" \
-SamAccountName "svc-backup-admin" \
-Description "Backup Service Account - DO NOT DISABLE" \
-PasswordNeverExpires $true \
-Enabled $true \
-Department "IT Operations"
# Set a password (this is never actually used by any real service)
Set-ADAccountPassword -Identity "svc-backup-admin" \
-NewPassword (ConvertTo-SecureString "$(openssl rand -base64 32)" -AsPlainText -Force)
# Do NOT add this account to any real group or service
# Alert on any login attempt: Event IDs 4625 (failed) and 4624 (successful) for this account
# A successful login means the attacker has valid credentials and is using them
3. Network Honeypots
A full-network honeypot is a host that responds to network service probes: RDP, SSH, SMB, HTTP: and alerts when any connection is received. Since no legitimate traffic should target this host, any probe is a port scan or exploitation attempt.
OpenCanary (open source, from Thinkst):
pip install opencanary
# Generate a config
opencanaryd --copyconfig > /etc/opencanary.conf
# Configure services to emulate (SSH, HTTP, SMB, RDP, etc.)
# Set up alerting to your SIEM via syslog or email
opencanaryd --start
OpenCanary emulates common services and logs all connection attempts with source IP, port, and protocol. Deploy it on an unused IP address in your internal network: any internal host scanning or probing that IP is performing reconnaissance.
What Honeypots Detect and What They Miss
What honeypots detect well:
- Reconnaissance: Port scanners, network discovery tools (nmap), AD enumeration tools (BloodHound, PowerView) that discover and probe the honeypot
- Lateral movement: Attackers who compromised one host and are moving to others will scan the network and reach honeypots
- Insider threats: A malicious insider browsing to file shares they should not access will hit canary files
- Credential testing: Attackers testing dumped credentials against multiple accounts will hit honey accounts
- Phishing kit harvesting: Automated bots scraping websites for email addresses will trigger web canary tokens embedded in HTML
What honeypots miss:
- Direct targeted attacks: If the attacker knows exactly which systems are real and goes directly to them without any reconnaissance phase, they will not trigger honeypots
- Exfiltration: An attacker who exfiltrates data directly from a compromised system without triggering any honeypots will go undetected: honeypots catch explorers, not targeted operators who know exactly where the data is
- Zero-click attacks: Supply chain attacks or watering hole attacks that do not involve any network reconnaissance
Alert quality: Honeypot alerts are actionable. When a canary token fires, something is wrong. Compare this to IDS alerts which have false positive rates that make many organizations tune them down to nearly useless.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
When Honeypots Make Sense (and When They Don't)
Deploy honeypots when:
- You have basic detection infrastructure (SIEM, EDR) in place: honeypots are a supplementary layer, not a foundation
- You have a team that can respond to alerts, because a honeypot alert is a high-priority incident
- Your environment has lateral movement risk: internal attackers (compromised external access, phishing) who need to explore the network to find data
- You want to detect threats that bypass perimeter controls: insider threats, credential-stuffing, living-off-the-land attackers
Do not rely on honeypots when:
- You have no incident response process: a honeypot alert you cannot act on has no value
- Your alert volume is already overwhelming: adding another alert source without response capacity increases noise, not security
- You expect targeted attackers who know your environment in detail: sophisticated APTs often honey-pot-check before acting
Starting point for most organizations:
- Deploy 5-10 canary tokens in high-value locations (admin wikis, file servers, credential stores) using Canarytokens.org: free, 20 minutes to set up
- Create one honey AD account with a believable name and alert on any authentication attempt
- Add an unused internal IP to your SIEM alert: any traffic to this IP from internal hosts is scanning
This costs nothing and provides detection coverage for reconnaissance and lateral movement that signature-based controls miss.
The bottom line
Honeypots detect attackers during reconnaissance and lateral movement with near-zero false positives: any access to a decoy resource is an alert, because legitimate users have no reason to be there. Canary tokens (fake AWS keys, Word documents, DNS hostnames) are free and deploy in minutes. Honey AD accounts alert on credential stuffing. Network honeypots catch internal port scans. They do not replace SIEM or EDR but add high-confidence detection coverage for the exploration phase of an intrusion that most signature-based controls miss.
Frequently asked questions
What is a honeypot in cybersecurity?
A honeypot is a decoy resource: a fake server, network share, user account, file, or credential: with no legitimate business purpose that alerts when accessed. Because legitimate users and systems have no reason to interact with it, any access indicates attacker reconnaissance or lateral movement. Honeypots generate high-confidence, low-noise alerts and detect attacker behavior rather than known attack signatures.
What is a canary token and how does it work?
A canary token is a digital trap that sends an alert when accessed: a web URL that beacons when fetched, a Word document that calls back when opened, a fake AWS access key that triggers a CloudTrail alert when used, or a DNS hostname that alerts when resolved. They are embedded in locations attackers would explore (config files, file shares, credential stores) and alert when an attacker reads or uses them. Canarytokens.org provides free deployment for common types.
What is the difference between a honeypot and a honeynet?
A honeypot is a single decoy system (server, workstation, or service) designed to attract and detect attacker activity. A honeynet is a network of honeypots with monitoring infrastructure between them: routers, firewalls, and analysis tools that capture all attacker traffic flowing through the decoy network. Honeynets allow observation of multi-stage attacks and lateral movement between systems. For most organizations, individual honeypots (or canary tokens placed strategically) provide high-value early warning detection with much lower operational complexity than maintaining a full honeynet.
Where should I place honeypots in my network for maximum detection value?
Place honeypots at locations that legitimate users have no reason to access but attackers will: a fake admin share on every file server (\\FILESERVER\admin$ with a canary document inside), a decoy domain admin account with a canary token password that beacons if used, an SSH server on an internal subnet with no real purpose, and a fake database server with a high-value name. Any access to these resources is an immediate high-confidence indicator of compromise: there is no legitimate business reason to touch them. Alert on any authentication attempt or network connection to these decoy systems with P1 severity.
What are the legal considerations for deploying honeypots?
Honeypots deployed on your own network to detect unauthorized access to your own systems are generally legal in all jurisdictions: you are the authorized owner. Legal complexity arises when: the honeypot actively engages or manipulates an attacker (potential entrapment issues, though entrapment typically applies only to law enforcement); the honeypot inadvertently captures third-party traffic; or you share honeypot data with law enforcement (chain of custody and evidence integrity requirements). Active honeypots that 'hack back' at detected attackers are illegal in most jurisdictions without specific legal authority. Consult legal counsel before deploying honeypots in regulated industries or before using honeypot evidence in criminal proceedings.
How do you tune honeypot alerts to avoid alert fatigue from automated scanners?
Honeypots generate high-confidence alerts, but internet-facing honeypots and poorly placed internal ones can produce volume from automated scanners and misconfigured systems that dulls response urgency. For internal honeypots, alert fatigue is rare if placement is correct: an internal IP that no legitimate traffic ever reaches should have near-zero alert volume. If you see regular traffic to an internal honeypot, investigate whether a misconfigured service or monitoring tool is scanning the network on a schedule. For internet-exposed honeypots used for threat intelligence gathering, suppress alerts from known mass-scanner IP ranges (Shodan, Censys, security research organizations publish their scanner IP lists) and alert only on interactive sessions rather than automated probes. Add an alert frequency threshold: if the same external IP triggers the honeypot more than five times in five minutes, it is a scanner rather than an attacker performing targeted reconnaissance. For canary tokens embedded in internal documents, the alert volume is inherently low because the token only fires when someone opens the specific document. The key tuning principle is matching the honeypot type to the detection goal: network honeypots for internal scanning detection, canary tokens for file and credential access detection, and honey accounts for credential stuffing detection each have different expected alert profiles.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.