What Is a Honeypot in Security and How Does It Catch Attackers?

A honeypot is a decoy system, service, file, or account that exists for one reason only: to be attacked. Since no real user or process has any business touching it, every login attempt, port scan, or file access it records is suspicious by definition. That is the whole trick behind honeypots in security: instead of trying to separate malicious traffic from normal traffic, you build something that only attackers would ever find interesting, then watch what they do.

The payoff is detection with almost no false positives, plus a front-row seat to an attacker's actual tools and behaviour while your real systems stay untouched.

What Is a Honeypot in Security?

Think of a honeypot as a shop window with a fake wallet in it. Nobody walking past has a reason to reach in. The moment a hand appears, you know exactly what kind of person you are dealing with.

In technical terms, a honeypot is a resource whose value comes entirely from being probed, attacked, or compromised. It can be:

• A server that looks like an unpatched database with a weak password
• A single fake SSH service listening on port 22 of an otherwise quiet machine
• An unused Active Directory account named svc_backup_admin that nobody should ever log in as
• A spreadsheet called payroll_2024_final.xlsx that phones home when opened
• A fake API key sitting in a code repository

Security teams usually split them into two camps. Production honeypots sit inside a real network to catch intruders early and buy defenders time. Research honeypots sit on the open internet to collect malware samples and study attacker behaviour, which is exactly what groups like The Honeynet Project have been doing since 1999.

How a honeypot catches an attacker, step by step

Attackers rarely know where they landed. After breaching a network, most of them move the same way: look around, list what is reachable, and try the easiest thing first. A honeypot is built to be that easiest thing.

1. Discovery. The attacker scans the internal subnet or the public IP range and finds the decoy, which advertises tempting services like SMB, RDP, MySQL, or an old web admin panel.
2. First contact. They connect. The honeypot logs the source IP, timestamp, user agent, TLS fingerprint, and the exact protocol handshake.
3. Credential attempts. They try passwords. A honeypot records every username and password combination, which quickly shows whether you are facing a broad password spray or a targeted attempt using leaked employee data. The pattern in those logs is often the fastest way to tell credential stuffing apart from a plain brute force attack.
4. Fake success. A medium or high interaction honeypot lets them "in" to a sandboxed shell or a mock filesystem.
5. Behaviour capture. Now the useful part: every command typed, every file downloaded, every script uploaded, every outbound connection attempted. Cowrie, a widely used SSH honeypot, even records terminal sessions you can replay keystroke by keystroke.
6. Alert and response. The security team gets a high-confidence alert, blocks the source, hunts for the same indicators elsewhere in the environment, and keeps the malware sample for analysis.

Because the honeypot terminates the session itself, it sees the attacker's commands in plain text.

Types of honeypots, from fake ports to full fake networks

The main design choice is how much you let the attacker actually do. More interaction means richer intelligence and more risk.

Specialised variants exist for almost every protocol. There are ICS honeypots imitating programmable logic controllers, database honeypots that answer MySQL and MongoDB handshakes, email honeypots (spam traps) that collect nothing but unsolicited mail, and malware honeypots designed to catch worms that spread over SMB.

Honeytokens and fake credentials: bait that fits in a file

You do not need a whole server to run a security trap. A honeytoken is a piece of data that has no legitimate use, so any use of it is an incident. These are the cheapest and often the most effective form of deception technology. Commercial deception platforms apply the same idea at scale, placing decoy hosts and honeytokens across a whole network and feeding every touch into one alert queue.

• Fake cloud keys. An AWS access key placed in a private repo or a config file. If it ever shows up in an authentication attempt, someone read code they should not have.
• Decoy accounts. A dormant domain account with an attractive name and no real permissions. Any authentication attempt against it is a red flag.
• Canary documents. A Word or PDF file that requests a remote resource when opened, revealing that a stolen document was viewed and roughly where.
• Poisoned database rows. A fake customer record with a unique email address. If that address receives mail, your customer table leaked.
• Decoy key material. A fake private key file that looks like a real keyring. If someone tries to use it, you know your key storage was searched. Real key and token handling is a separate discipline; read secrets management best practices before planting bait next to real secrets.

Honeypot vs intrusion detection system

People often ask whether a honeypot replaces an intrusion detection system. It does not. They answer different questions and work best side by side.

An IDS gives you coverage. A honeypot gives you certainty. MITRE's Engage framework for adversary engagement treats deception as a complement to monitoring, not a substitute.

The honeypot field in web forms

There is a second, much smaller meaning of the word that web developers use daily. A form honeypot is a hidden input field that humans never see and never fill in. Automated spam bots parse the raw HTML, see a field named something like website_url, and fill it out because they fill everything out.

If that field arrives with a value, the submission is discarded silently. Two details make it work:

• Hide the field with CSS, not the hidden attribute, since smarter bots skip hidden inputs.
• Add tabindex="-1" and aria-hidden="true", use a field name that does not trigger browser autofill, and keep autocomplete="off" as a hint only.

It costs nothing, adds no friction for real users, and stops a large share of low-effort bot spam. It will not stop a determined attacker targeting your site specifically.

Risks, limits, and legal considerations

A honeypot is a system you are deliberately inviting people to break into, which creates obligations.

• It can become a launchpad. A compromised high-interaction honeypot with unrestricted outbound access can be used to attack others. Always apply strict egress filtering and rate limits.
• It can be fingerprinted. Experienced attackers check for telltale signs: unrealistic uptime, no user files, emulated shells that respond oddly. A honeypot that screams "honeypot" just tells the attacker to be careful elsewhere.
• It sees nothing outside itself. An intruder who walks straight to your file server and never touches the decoy leaves no honeypot trace at all.
• It does not protect real data. Deception buys detection time. Your actual sensitive data still needs proper access control and strong cryptography, ideally an approach where the service itself cannot read what you store, which is the point of zero knowledge encryption.
• Legal and privacy rules apply. You are recording activity, sometimes including personal data. Entrapment concerns are mostly a myth for private operators, since you are not law enforcement inducing a crime, but logging, retention, and jurisdiction rules still apply. Check with legal counsel before deploying on the public internet. Under the GDPR, attacker IP addresses count as personal data, so set a short retention period and record why you log them.

A famous early example is Cliff Stoll's hunt in 1986: the astronomer traced a 75 cent accounting error at Lawrence Berkeley Lab to a real intruder, then fed him a fake "SDINET" archive of invented military documents to keep him online long enough to trace the call. That story, told in The Cuckoo's Egg, is often cited as one of the first documented honeypot operations.

How to start small with a honeypot

You do not need a lab budget. A useful first deployment looks like this:

1. Pick one decoy that fits your actual risk. If you run a Windows domain, a fake privileged account is more useful than an SSH honeypot.
2. Isolate it. Separate VLAN, no trust relationships, no shared credentials with production, tight outbound rules.
3. Ship logs off the box immediately. If the honeypot is compromised, the attacker can edit local logs. Remote syslog or a SIEM feed keeps evidence intact.
4. Route alerts somewhere a human reads. A honeypot alert should be treated as a confirmed incident, not another line in a dashboard.
5. Sprinkle honeytokens widely. They are cheap to create, but each needs an owner and an alert route. They cover the ground your single decoy host cannot.
6. Review quarterly. Refresh fake file timestamps, rotate decoy credentials, and confirm the bait still looks alive.

Open source options worth knowing by name: Cowrie for SSH and Telnet, Dionaea for malware capture, Conpot for industrial control protocols, and OpenCanary for lightweight network decoys. All are free; check each project's maintenance status before relying on it.

Sharing real credentials while you set up your security traps?

Honeypots use fake credentials as bait, but the genuine passwords and keys behind your decoy network still need a safe way to travel. Our free privacy tools let you hand over secrets without leaving them sitting in chat logs or email.

Try our free privacy tools →

Frequently asked questions