What are honeypots and how do defenders use them safely?

A honeypot is a decoy system or resource that nobody legitimate has a reason to touch, so any contact is a signal. Defenders use honeypots to detect intruders early and to learn how attackers behave. The risk is that a poorly isolated decoy becomes a foothold, so isolation matters more than realism.

What is the official definition?

The NIST glossary, citing CNSSI 4009 and IETF RFC 4949, defines a honeypot as a system, for example a web server, or a system resource, for example a file on a server, designed to be attractive to potential intruders, like honey is attractive to bears. Note the second half: a decoy file or credential counts too, not only a whole machine.

What kinds are there?

• Low interaction. Emulates a few services, such as a fake SSH banner or database port. Cheap and safe, and good for spotting scans and credential guessing.
• High interaction. A real operating system with real services, instrumented heavily. It shows what an attacker does after getting in, and it carries real risk.
• Honeytokens. Fake credentials, API keys, database rows or documents with no real function. They alert when used. These are the easiest to start with.
• Honeynets. A set of decoys that look like a small network.
• Research versus production. Research honeypots sit on the open internet to collect samples. Production honeypots sit inside your network to catch lateral movement.

Why are internal honeypots so effective?

Real systems generate noise: logins, jobs, traffic, mistakes. A decoy that has no business purpose generates none. Any connection to it is suspicious by construction, so false positives are rare. That is the opposite of most detection, which hunts for a bad event in a sea of normal ones.

Constructed example: a company places a file named backup-credentials in a shared drive folder, containing an access key that is valid only for a monitoring rule. No employee needs it. Three weeks later an alert fires because that key was used from an unfamiliar address. The security team now knows a user account was compromised and where the attacker looked first, before any real data moved.

What are the risks?

• Pivoting. If an attacker takes over a high interaction decoy and it can reach real systems, you built them a stepping stone. Isolate it on its own network segment with strict egress rules.
• Fingerprinting. Experienced attackers can recognize emulated services and avoid them or feed them junk.
• False comfort. A quiet honeypot does not mean no attacker is present. It only means none touched it.
• Legal and policy questions. Collecting data about visitors, and any entrapment arguments, vary by jurisdiction. Involve counsel before deploying decoys on public networks.
• Maintenance. An unpatched decoy that nobody watches is just a vulnerable server.

How to check or apply this

1. Start with honeytokens: a decoy credential, a canary database row and a bait document, each with a unique identifier so an alert tells you where it leaked from.
2. Decide who receives the alert and what they do. An alert with no owner is wasted.
3. Place decoys where an intruder would look next: credential stores, shared drives, source repositories, cloud metadata paths.
4. If you deploy a decoy host, give it its own segment, no route to production and logging sent to a separate system.
5. Make decoys believable: plausible names, realistic age and a few harmless real looking files.
6. Review hits monthly and rotate the tokens.
7. Document it internally so your own team does not mistake a decoy alert for a real incident, or the reverse.

Once a decoy fires, you can use the MITRE ATT&CK knowledge base to look up what the intruder may do next, such as network sniffing under T1040.

Quick check

Sources

• NIST Computer Security Resource Center glossary, honeypot
• MITRE ATT&CK
• MITRE ATT&CK T1040, Network Sniffing

Last reviewed: 18 October 2026.