What Is a Honeypot in Cybersecurity? Types, Deployment, and Detection Use Cases (2026)

A honeypot is a security resource whose value lies entirely in being attacked. It looks like a legitimate target — a database, an admin account, a file share, a misconfigured cloud key — but in reality it has no legitimate users, no real data, and one job: when someone touches it, raise an alarm. The first interaction is the alarm, and that’s why honeypots routinely deliver detection in minutes for techniques that signature-based EDR misses entirely. This guide answers what is a computer honeypot in 2026, walks through the practical taxonomy (low- vs high-interaction, production vs research), and shows the deployment patterns and SIEM integration that actually catch attackers rather than wasting blue-team time.

TL;DR — honeypots in one screen

• A honeypot is a decoy that has no legitimate use. Any access = malicious by definition. Zero false positives by design.
• Two axes split the field: interaction level (low / medium / high) and purpose (production / research).
• The 2026 sweet spot for most blue teams: low-interaction service emulators in production (Cowrie, Conpot, T-Pot bundle) plus AD honeyaccounts and Canarytokens scattered through file shares and code repos.
• High-interaction honeypots (full systems) are research tools — they catch novel tradecraft but need careful network isolation; one compromised honeypot becomes a pivot point.
• The detection model is simple: forward every honeypot event to your SIEM, alert at threshold = 1. No tuning needed. No false-positive triage.

What is a honeypot, exactly?

A honeypot is an information system resource whose value lies in being probed, attacked, or compromised. It is not a real production service — it has no real users, no real data, no business function. Its sole purpose is to detect, deflect, or study unauthorised access.

The defining property: there is no legitimate reason for anyone to touch it. That makes every interaction a high-fidelity signal. Compare to a typical SIEM rule on failed login > 100 in 5 minutes — full of false positives from typo’d passwords, expired credentials, automated scanners. A honeypot fires once per real attacker.

The term traces back to Cliff Stoll’s The Cuckoo’s Egg (1989), and to Lance Spitzner’s foundational work on the Honeynet Project in 1999. Two decades later the technique is firmly in mainstream blue-team practice — MITRE D3FEND lists deception as a primary defensive category, and modern detection engineering curriculum (SANS, RangeForce, MITRE Engage) all teach honeypot deployment as a baseline.

Why deploy honeypots in 2026

Four concrete reasons honeypots remain top-tier blue-team investment:

1. Modern attackers are quiet inside the network. Mandiant’s 2024 M-Trends report measured median dwell time at 10 days. Most of that time, attackers are doing reconnaissance — querying LDAP, browsing shares, reading SharePoint. Honeypots planted in exactly those reconnaissance paths fire the moment they’re touched, compressing detection from days to minutes.

2. Honeypots catch what signatures miss. Living-off-the-land techniques (BloodHound enumeration, AD recon via PowerView, SharpHound, SoaPy) generate normal-looking SMB/LDAP traffic. They don’t trip Defender. They DO trigger a honeyaccount Kerberos request.

3. Zero false positives is a real operational win. SOC analysts spend the majority of their day triaging alerts that turn out to be benign. A honeypot alert is by definition true-positive. It’s the highest-fidelity input you can feed into your SOAR playbooks.

4. Honeypots are cheap. Cowrie runs on a $5/month VPS. Canarytokens are free. AD honeyaccounts are creating-disabled-user-account free. The detection lift vs. the spend is asymmetric.

The honeypot taxonomy

By interaction level

For most blue teams the answer is low- and medium-interaction. High-interaction honeypots produce richer intelligence but the operational cost is meaningful: full network isolation, automated rebuild after each compromise, dedicated analyst time. Reserve them for research roles or threat-intel teams.

By deployment role

The two roles are not interchangeable. Production honeypots are blue-team detection; research honeypots are threat-intelligence feeds.

The honeypot tool landscape

A working reference of what to deploy for which use case:

How to deploy a honeypot in your environment

The full safe-rollout sequence:

Each step is expanded with concrete commands below.

Step-by-step: deploying T-Pot (low-effort starting point)

T-Pot bundles 20+ honeypots (Cowrie, Dionaea, Conpot, ElasticPot, Heralding, Honeytrap, more) into a single Docker-Compose stack with an Elastic dashboard. It’s the fastest way to get visibility against opportunistic attackers.

# Provision a dedicated host — never on a production server
# Minimum: 8 GB RAM, 64 GB disk, public IP (for internet research role)

apt-get update && apt-get -y install git
git clone https://github.com/telekom-security/tpotce
cd tpotce
./install.sh -t SENSOR -y                  # SENSOR = headless; HIVE adds Kibana

# Confirm services
docker ps --format 'table {{.Names}}\t{{.Status}}'

# Each honeypot logs to /data//log/
tail -f /data/cowrie/log/cowrie.json | jq '.username, .src_ip'

Within minutes of exposure to the internet you’ll have credentials, payload URLs, and attacker IPs piling up. For research-role honeypots that’s the goal. For production-role honeypots do not expose to the internet — deploy on an internal IP that mirrors a real server.

Step-by-step: deploying Cowrie inside the network

Cowrie is the most useful single honeypot tool — medium-interaction SSH that captures credentials, command-line activity, and downloaded payloads.

adduser cowrie --disabled-password
su - cowrie
git clone https://github.com/cowrie/cowrie
cd cowrie
python3 -m venv cowrie-env && source cowrie-env/bin/activate
pip install -r requirements.txt

# Configure
cp etc/cowrie.cfg.dist etc/cowrie.cfg
# Edit:
#   hostname = fileserver-04           (match your real naming)
#   listen_endpoints = tcp:2222:interface=0.0.0.0
#   download_path = /opt/cowrie/dl

# Redirect port 22 to 2222 (cowrie can't bind <1024 unsupervised)
sudo iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 2222

bin/cowrie start

Every credential attempted, command typed, and file downloaded is logged to var/log/cowrie/cowrie.json — perfect for SIEM ingest.

Production honeypot patterns that work

1. AD honeyaccount

A disabled, never-logged-on AD account with a tempting name (svc-backup-2026, admin-old, sql-svc). Register an SPN on it so Kerberoasting tools (Rubeus.exe kerberoast) request a TGS — and every TGS request for that SPN generates Event ID 4769 with a known, unused account name.

# Create the honeyaccount
$pwd = ConvertTo-SecureString (-join ((33..126) | Get-Random -Count 32 | %{[char]$_})) -AsPlainText -Force
New-ADUser -Name "svc-backup-old" -SamAccountName "svc-backup-old" `
  -AccountPassword $pwd -Enabled $false `
  -Description "Decommissioned backup service account (DO NOT USE)"

# Register a tempting SPN
Set-ADUser svc-backup-old -ServicePrincipalNames @{Add="MSSQLSvc/sql01.corp.local:1433"}

# SIEM rule: any 4769 event with ServiceName CN=svc-backup-old → alert

This is one of the highest-ROI honeypots in the entire AD ecosystem. Paired with the Kerberoasting detection guide, it catches every BloodHound-driven enumeration that touches kerberoast mode.

2. SharePoint / file-share Canarytoken

Place a file called passwords.docx or aws-credentials.xlsx somewhere visible (a SharePoint site, a domain admin’s user share, the IT department’s wiki). Use Canarytokens.org to generate a tokenised Microsoft Word doc. When the file is opened, a DNS / HTTP callback fires to your alerting endpoint.

Attackers in lateral-movement phase always grep for password, secret, cred — and the moment one of them opens this file, you have an IP + UA + timestamp.

3. Cloud-key tokens

The same idea, but for AWS / Azure / GCP credentials. Drop an AWS-token-keypair into a Git repo named prod-keys.tar.gz. Every time an attacker tries to authenticate with those keys, CloudTrail logs the API call from the attacker’s IP. Use CanaryToken AWS Access Key or generate via Thinkst Canary.

4. Honey-DNS records

Add a fake DNS A record like backup-sql.corp.local pointing to a Cowrie host. Internal attackers running nslookup -type=A *.corp.local or DNS sweeps via dnsrecon will discover it. Any connection to that IP = alert.

Detection use cases — wiring honeypots into your SIEM

The detection model is simple: every honeypot event is a true positive. No tuning. No thresholds. No allow-lists. Just route the events to your SIEM and alert at threshold = 1.

Splunk

index=honeypot
| stats count by src_ip, dest_host, session_id
| eval severity="critical"
| sendalert siemresponse param.message="Honeypot interaction detected"

Microsoft Sentinel (KQL)

SecurityEvent
| where EventID in (4624, 4625, 4769)
| where TargetAccount has_any (dynamic(["svc-backup-old", "admin-decommissioned"]))
| project TimeGenerated, Computer, Account, IpAddress, ActivityType
| extend Severity="High"

Elastic SIEM

- name: "Honeypot interaction"
  index: ["filebeat-cowrie-*", "filebeat-canary-*"]
  query: "*"
  type: query
  severity: critical

The simplicity is the point. A honeypot rule has no tuning logic because every event is by-definition malicious.

Common mistakes (and how to avoid them)

Twelve recurring failures in honeypot deployment:

Operational considerations

A few practical things that bite first-time deployers:

• Legal review. In some jurisdictions, deploying a honeypot that captures attacker PII (IP, browser fingerprint) has data-protection implications. Run it past legal before going live.
• Communication with IT operations. Network monitoring will flag the honeypot’s traffic; your sysadmins will see “strange new VM” in monitoring; document it.
• Rotation. Static honeypots eventually get fingerprinted (especially research role). Cycle banners, ports, and filenames every 60-90 days.
• Detection-engineering pairing. Use honeypot alerts as input to your detection-engineering pipeline. Each alert is a labelled, high-confidence ground-truth attack event — gold for tuning rules elsewhere in your SIEM. The Splunk detection-engineering guide covers how to use these alerts as a feedback loop.

Frequently asked questions

Conclusion: deploy one honeypot this week

The smallest meaningful step you can take: create one AD honeyaccount with an SPN, wire the Event 4769 alert into your SIEM, and document it in your inventory. That’s a one-hour engagement and it catches Kerberoasting from BloodHound, Rubeus, and Impacket — the toolkit of every modern AD attacker.

From there, layer in:

1. One Canarytoken document on the IT-department SharePoint site
2. One Cowrie SSH honeypot mirroring your real server-naming convention
3. A SOAR playbook that auto-isolates any internal host that has touched a honeypot in the prior 15 minutes

That’s a complete deception layer in roughly a week of part-time work. The detection lift vs. the spend is the highest in modern blue-team practice — there’s nothing else that delivers true-positive alerts with this little effort.

For related Windows and AD hardening that pairs naturally with honeypot detection, see the Windows LAPS implementation guide (which closes the credential-reuse vector your honeypots are designed to detect being abused), the Kerberoasting deep dive (which explains the attack your AD honeyaccount catches), and the Splunk detection-engineering tutorial for the SIEM-side rule construction.

Share this guide

LinkedIn:

A computer honeypot is the cheapest, highest-fidelity detection control in modern blue-team practice — zero false positives by design. The 2026 deployment playbook: AD honeyaccounts, Canarytokens, T-Pot for research role, and the SIEM rule that needs no tuning. 👇

X / Twitter:

Honeypots in 2026: low-interaction (Cowrie/T-Pot) + medium (Canarytokens) + AD honeyaccounts with SPNs = full detection coverage for the techniques EDR misses. Detection rule: threshold=1. No tuning. No false positives. Full guide:

References

• MITRE D3FEND: Deception techniques — the defensive framework’s deception branch
• MITRE Engage — the dedicated engagement and deception framework
• The Honeynet Project — the foundational community resource
• Cowrie SSH/Telnet honeypot
• Dionaea multi-protocol honeypot
• Conpot ICS honeypot
• T-Pot all-in-one bundle
• Canarytokens.org — free tokenised tripwires from Thinkst
• Thinkst Canary — commercial honeypot appliance
• SANS: Honeypots, Deception, and Cyber Threat Intelligence — practitioner research