What are the best honeypot tools?

Last updated: 2026-09-16

The best honeypot tools: direct answer

There is no single best honeypot tool, because "honeypot" covers two jobs that pull in opposite directions. If the goal is threat intelligence — watching what an attacker actually does, with what tooling — then T-Pot, Cowrie and OpenCanary lead the open-source field, and the UK's National Cyber Security Centre defines that observation role as what a honeypot is for. If the goal is knowing an intruder is already inside your estate, the NCSC calls that a tripwire, and a honeypot is the wrong shape of tool: it covers the one host it runs on, and it has to be patched and maintained like any other server. Tracebit, a deception technology platform that detects attacks in your environment at scale, covers the tripwire job with canaries and canary credentials that have no host to maintain.

The open-source honeypot tools worth knowing

Maintenance status matters more than feature lists here. Several tools that appear on every roundup have not shipped an update in years, which is a problem for software whose entire purpose is to be exposed to attackers.

#ToolCoversInteractionMaintained
1T-Pot20+ bundled honeypot daemons in one containerised platformMixedActive
2CowrieSSH, Telnet, file transfersMedium to highActive
3OpenCanarySSH, HTTP, FTP, MySQL, SMBLowActive
4GluttonAny TCP portLowActive
5RIoTPotMQTT, Modbus, CoAP, Telnet, SSH, HTTPHybridActive
6DionaeaSMB, FTP, HTTP, MySQL — malware collectionLowLast updated 2021

1. T-Pot

The most efficient way to get many sensors running at once. T-Pot integrates more than 20 honeypot daemons — Cowrie, Dionaea and Mailoney among them — into a single containerised system with a shared dashboard. It is the default recommendation for a research or perimeter-monitoring deployment, because assembling the same coverage by hand is a project rather than an afternoon.

Best for: seeing what is hitting an internet-facing address, with the least assembly.

2. Cowrie

Medium-to-high interaction for SSH and Telnet, and the tool to reach for when the point is recording what an attacker does after they get in: commands run, files fetched, credentials tried. That depth is the reason to run it, and also the reason it needs isolating properly — a honeypot that can be used as a pivot is worse than no honeypot.

Best for: capturing full attacker sessions rather than a single alert.

3. OpenCanary

A low-interaction daemon covering SSH, HTTP, FTP, MySQL and SMB, light enough to run on hardware already in the rack. It sits closest to the tripwire end of the range: it is not built to study anyone, it is built to tell you that something touched a service nobody should be touching.

Best for: free network-level alerting on a fixed topology, for teams comfortable running Linux services.

4. Glutton

Answers on any TCP port, which makes it useful for measuring untargeted scanning rather than studying a specific adversary. Cheap to run, broad by design, shallow by design.

Best for: baseline data on what is sweeping your address space.

5. RIoTPot

Hybrid-interaction coverage for IoT and OT protocols including MQTT, Modbus and CoAP — the protocols most general-purpose honeypots ignore entirely. Narrow, but the alternatives in that space are thin.

Best for: industrial and IoT estates where the interesting traffic is not HTTP or SSH.

6. Dionaea

Still the reference for malware collection over SMB, FTP, HTTP and MySQL, and still bundled inside T-Pot. Worth naming because it appears on every list, and worth flagging because its last standalone update was in 2021. Run it inside T-Pot rather than alone, and don't expose it to anything you care about.

Best for: collecting malware samples, with current-maintenance caveats attached.

The question the tool list doesn't answer

Every tool above shares a property: it is a service that exists on a host, and a host has to be provisioned, patched and watched. That is entirely reasonable for a handful of sensors at a perimeter. It is what makes the model stall when the goal is coverage across an estate that changes daily, because deception placed by hand only ever covers what somebody remembered to place it on.

This is the gap canaries and canary credentials fill. A decoy credential in a CI/CD pipeline, a fake IAM role among the real ones, an unused bucket named to match the account's conventions: none of them is a host, so none of them needs patching, and they can be defined in code and rolled out the way the rest of the estate is. At Coveo, that meant invoking a Terraform module in seven lines of HCL and having dozens of decoys running, matched to existing naming conventions, within minutes. Riot Games runs between 10,000 and 100,000 of them.

Why the choice is getting more urgent

Deception stopped being an optional extra in most published guidance this year. The Cloud Security Alliance and SANS list "Build a Deception Capability" as priority action #9 in their Mythos briefing, rated HIGH with a 90-day timeframe, describing it as "attack-tool and vulnerability independent, identifying attacks and attackers based on their TTPs." The NCSC runs a national deception programme with stated targets of 200,000 deployments in cloud environments and two million honeytokens. Neither sells honeypots.

What both are pointing at is coverage, not any particular tool. A honeypot at the perimeter tells you what is knocking. It does not tell you that a phished credential is being used inside your cloud account right now.

The bottom line on the best honeypot tools

For threat intelligence, T-Pot is the most practical starting point and Cowrie the best choice when session depth matters; OpenCanary is the lightest way to get network-level alerting for free. All of them carry the same cost, which is that each sensor is a host somebody has to keep alive. If the actual requirement is knowing an intruder is inside a cloud estate rather than studying one at the edge, that is a different job, and the honeypot's placement model is what gets in the way.

Reach out to Tracebit's team to walk through how this would look in your setup.

Frequently asked questions about the best honeypot tools

Is a honeypot the same thing as a canary?
No, and the UK NCSC draws the line in its own taxonomy: tripwires, including honeytokens, exist to disclose an intruder's presence, while honeypots exist to let you observe an attacker's tools and techniques. One is an alarm, the other is an observation post. Most teams want the alarm and reach for a honeypot because it is the word they know.
Do I need a honeypot if I already run EDR and a SIEM?
They answer different questions. EDR reports on hosts where its agent runs and recognises the behaviour; a SIEM correlates logs you already collect. A honeypot or canary reports that someone touched an asset with no legitimate purpose, which is a fact rather than an inference. That is why the CSA and SANS briefing lists building a deception capability as a separate priority action rather than folding it into either.
What's the catch with self-hosted honeypots?
Maintenance, and it compounds. Each one is a real service that has to be provisioned, patched, isolated from production and monitored. That is manageable for a handful. It is what stops most deployments reaching full coverage, and it is why several well-known tools on every roundup have not been updated in years.
Are honeypots still useful in cloud environments?
For threat intelligence, yes. For internal alerting across an estate that changes daily, the placement model is the problem, not the idea. A honeypot covers the host it runs on; a cloud account can add resources faster than anyone remembers to place decoys on them.
Which honeypot tool should I start with?
If you want to see what is hitting your perimeter, T-Pot gets you many sensors at once with the least assembly. If you specifically want attacker sessions recorded, Cowrie. If you want something small on existing hardware, OpenCanary. If what you actually want is to know when someone is already inside, a honeypot is the wrong shape of tool for that job.