Explained: Honeypots

Codelooru mythos

Information in this post reflects publicly available knowledge on honeypot techniques as of June 2026.

The trap that nobody walks into by accident

A small SaaS company spins up a new database server on a Tuesday afternoon. Nobody has announced it, no DNS record points to it yet, and no employee has the credentials. By Wednesday morning, the logs show seventeen login attempts from six different countries.

Nothing about that server was advertised. The only way to find it was to scan the internet's address space looking for open ports, which is exactly what automated bots do, constantly, against every reachable IP address. This is the backdrop that makes a honeypot work: a decoy system that has no legitimate reason to ever be touched, so when something touches it, that something is almost certainly hostile.

A honeypot is a system, service, or piece of data deliberately deployed to look valuable to an attacker while serving no real business function. It exists purely to be found, probed, and interacted with, so that the defender can watch what happens next.


The problem honeypots solve

Most security tooling has to separate malicious activity from an enormous volume of legitimate traffic. An intrusion detection system watching a production web server sees thousands of normal requests for every suspicious one, and tuning out the noise without missing real attacks is a constant, imperfect balancing act.

A honeypot sidesteps that problem entirely. Because it serves no real users and has no legitimate business purpose, there is no "normal traffic" to filter out. Any connection, login attempt, or file access is automatically suspicious. This gives honeypots an unusually low false-positive rate compared to most other detection methods.

They also solve a second, less obvious problem: visibility into what attackers actually do once they think they have access. A firewall log tells you a connection was blocked. A honeypot lets the connection through and records every command an intruder types, every tool they upload, and every system they try to reach next.

INTERNET-WIDE SCANNING Scanning bot / attacker probes network Edge / firewall Real server (protected, patched) Honeypot (looks valuable, isn't) Every action logged tools, commands, IPs Mostly silent Real traffic stays quiet at the real server; attacker traffic walks straight into the honeypot

How a honeypot actually works

At its core, a honeypot just needs to do two things convincingly: look attractive enough that an attacker chooses to interact with it, and record everything that happens once they do. How deep that interaction goes is where honeypots split into two broad categories.

Low-interaction honeypots

A low-interaction honeypot simulates only the surface of a service. It might open a port and respond to a login prompt with a fake banner, or accept a connection and log the source IP and any commands sent, without ever running a real shell or operating system underneath. Tools like cowrie simulate an SSH or Telnet server this way.

These are cheap to deploy, safe to run at scale, and good for catching the bulk of automated, opportunistic scanning. Their weakness is depth: an attacker who realizes they're talking to a simulation rather than a real system will simply move on, and you lose the chance to see what they would have done next.

High-interaction honeypots

A high-interaction honeypot is a real or near-real system, a genuine operating system with genuine services running on it, deliberately exposed and monitored. An attacker who breaks in here can install malware, escalate privileges, and move around, all while every action is captured.

The intelligence value is much higher, but so is the risk. A high-interaction honeypot must be tightly isolated, typically inside its own network segment with strict outbound controls, so that a compromised honeypot can never become a launch point into real infrastructure. Getting this isolation wrong defeats the entire purpose of running one.

Honeytokens

Not every honeypot is a system. A honeytoken is a single piece of fake data planted somewhere sensitive: a credential in a configuration file that should never be used, a bogus customer record in a database, an API key embedded in code that should never be called. If that token is ever used, copied, or queried, it functions as a tripwire, since there is no legitimate reason for it to surface at all.

Honeytokens are useful precisely because they require almost no infrastructure. A single fake row in a database table can reveal that an attacker has read access to that table, long before any other alert would have fired.

LOW-INTERACTION HIGH-INTERACTION Simulated service only Cheap, safe, scalable Shallow data, easy to detect Real OS, real services Rich, detailed intelligence Higher risk, needs isolation Same goal, different trade-off: breadth and safety vs. depth and risk

Variants and edge cases

A honeynet scales the idea up from a single decoy to an entire fake environment: multiple interconnected honeypots designed to resemble a real corporate network, complete with fake workstations, fake file servers, and fake internal traffic. Honeynets are built to study lateral movement, since a single isolated honeypot can't show how an attacker pivots from one compromised machine to another.

Some honeypots are designed to be found internally rather than externally. An attacker who has already breached the perimeter and is exploring the internal network has no map of what's real. A few well-placed internal honeypots, sometimes called deception technology when deployed this way, can catch lateral movement that perimeter defenses never see, because the attacker is already past them.

There's also a meaningful legal and ethical edge case worth knowing about: a honeypot that goes beyond passive observation and actively interferes with an attacker's systems crosses into territory most jurisdictions treat as offensive hacking, regardless of who started it. Most organizations that run honeypots stick strictly to observing and logging, not retaliating.


Where you'll encounter honeypots in the real world

Research organizations and security vendors run large-scale honeypot networks purely to track what's happening on the internet at any given moment: which vulnerabilities are being actively exploited, which botnets are scanning, and which credentials show up most often in brute-force attempts. This data feeds threat intelligence feeds used across the industry.

Inside companies, honeypots and honeytokens are increasingly used as an early-warning layer that sits alongside traditional monitoring. A fake admin credential planted in a password manager, a decoy database table sitting next to a real one, or a dummy server on a network segment, all exist to catch an intruder who has already gotten further than the firewall ever expected.

Cloud providers and managed security services also use honeypots to study attack patterns targeting their own infrastructure, since the same scanning bots that hit a small company's new server hit cloud IP ranges constantly, and understanding that traffic at scale helps everyone downstream.

TIME Automated scan finds port Connects to honeypot Activity fully logged Alert triggered no false positive risk Security team reviews tooling, IPs, and techniques used

Summary

The honeypot's power comes from a simple asymmetry: a real user has no reason to find or touch it, so anything that does is meaningful by default. That single property turns a normally noisy problem, telling attackers apart from everyone else, into one of the cleanest signals available in security.

Whether it's a full fake server, a single fake credential, or an entire fake network, the underlying logic is identical. Build something that looks worth stealing, watch who tries, and let their own curiosity do the work of revealing them.

Part of the Explained series: concepts in tech, clearly.



×