A honeypot is a decoy system designed to look like a real target, such as a database, payment gateway, or login server, so that attackers interact with it instead of your actual infrastructure. While the attacker pokes around what they believe is a vulnerable machine, the honeypot quietly logs everything they do: the tools they use, the commands they type, the IP addresses they connect from, and the malware they try to install. The result is an early warning system that also doubles as an intelligence-gathering tool.
The Core Mechanism
A honeypot works by emulating a system that looks worth attacking. It might present outdated software, open network ports, or weak passwords, all deliberately configured to be tempting. Because no legitimate user has any reason to interact with the decoy, any connection to it is suspicious by default. That’s the key advantage over traditional security tools like firewalls or intrusion detection systems, which have to sort real traffic from malicious traffic. A honeypot skips that problem entirely.
To keep the rest of the network safe, honeypots are isolated from production systems. If an attacker does break in, they can’t use the decoy as a stepping stone to reach real servers or data. This isolation is critical because a poorly segmented honeypot could actually increase your attack surface rather than reduce it.
Low-Interaction vs. High-Interaction Honeypots
The biggest design choice in a honeypot is how much freedom you give the attacker once they connect. This is called the interaction level, and it creates a direct tradeoff between the quality of intelligence you collect and the resources and risk involved.
Low-interaction honeypots simulate only the surface layer of a system. They might mimic an SSH login prompt or a web server’s response headers without running a real operating system behind them. They’re simple to deploy, use minimal computing resources, and carry little risk because there’s no real system for the attacker to compromise. The downside is that experienced attackers can often recognize the simulation. Low-interaction honeypots also won’t catch sophisticated techniques like zero-day exploits, since they only offer basic responses to basic probes.
High-interaction honeypots run real operating systems and services, giving attackers a full environment to explore. This produces far richer data: you can watch an attacker escalate privileges, download additional tools, and attempt to move laterally. But they require significantly more resources to maintain and monitor, and they carry real risk. If isolation fails, the attacker has a genuine system they could weaponize.
Production vs. Research Deployments
Honeypots serve two distinct purposes depending on where and why they’re deployed.
Production honeypots sit alongside real servers inside an organization’s network. Their job is to detect breaches early. A financial institution, for example, might set up a honeypot that mimics a transaction server. If an attacker who has already penetrated the perimeter touches that decoy, the security team gets an immediate alert that someone is moving through the internal network. These deployments prioritize fast, reliable detection over deep analysis.
Research honeypots are built to study attacker behavior at scale. Universities and cybersecurity organizations deploy them to track how new malware strains spread, map botnet activity, or catalog the latest exploitation techniques. The data feeds into threat intelligence that benefits the broader security community. Research honeypots tend to be high-interaction, since the goal is to let attackers reveal as much of their playbook as possible.
What Data Honeypots Actually Capture
The logging capabilities go well beyond simple connection records. A well-configured honeypot captures the source IP address of every connection, the destination ports being targeted, the raw data transmitted over the network, and full packet captures that can be analyzed later. For SSH and Telnet honeypots, this includes every command the attacker types. For web-facing honeypots, it includes HTTP POST data, which often contains the payloads attackers are trying to deliver.
Packet captures are especially valuable because they preserve information that standard logs miss. Researchers at the SANS Internet Storm Center have used honeypot packet data to extract XML-based attack payloads submitted over unexpected ports, revealing scanning campaigns that would otherwise go unnoticed. Some operators run honeypots across multiple cloud providers simultaneously, correlating data from AWS, Google Cloud, and other platforms to build a broader picture of attacker activity across regions.
Honeytokens: Smaller, Targeted Traps
A honeytoken takes the same principle and shrinks it down to a single artifact instead of an entire system. These are fake items planted inside real environments, designed to trigger an alert the moment someone interacts with them. Common examples include:
- Credential tokens: Fake account logins for systems like Active Directory or cloud platforms. If anyone tries to authenticate with them, you know credentials are being harvested.
- Document tokens: Decoy PDFs or Word files with hidden tracking links. Opening one phones home to your monitoring system.
- Database tokens: Fake rows in database tables that no real application ever queries. Any access to those rows signals unauthorized browsing.
- API key tokens: Dummy keys embedded in code repositories. Attackers who scrape repositories for secrets will try to use them, revealing themselves in the process.
- Email tokens: Hidden email addresses that only appear in places an attacker would look. Any login attempt or message sent to that address is an alert.
Honeytokens are lightweight enough to scatter across an entire environment, creating a minefield of tripwires that an intruder has to navigate without knowing which items are real and which are bait.
Limitations and Risks
Honeypots are not a standalone defense. They only detect threats that directly interact with the decoy, so an attacker who never touches it goes completely unnoticed. Sophisticated attackers can sometimes fingerprint honeypots by identifying subtle differences between the decoy and a real system, then simply avoid them.
False alarms are a practical concern, particularly with honeytokens. If a legitimate employee accidentally modifies or deletes a decoy file, the system flags it as an intrusion. Organizations need clear internal processes so that real users don’t stumble into their own traps.
There are also limits to what honeypots can catch. Most decoy-file approaches assume that malware will read and encrypt the bait files in a predictable way. In reality, some ransomware performs data exfiltration or lateral movement before it ever touches the files designed to detect it. That gap means honeypots work best as one layer in a broader security strategy, not as the sole line of defense.
Legal Considerations
Deploying a honeypot means intentionally monitoring someone’s activity on your system, which raises questions about privacy law and, in some jurisdictions, entrapment. In the United States, the two primary legal issues are whether logging attacker communications violates wiretap statutes and whether luring someone into committing a crime could be considered entrapment. In practice, courts have generally treated monitoring activity on systems you own as permissible, but the specifics depend on how the honeypot is configured and what data it collects. Organizations deploying honeypots typically involve legal counsel to ensure their logging practices comply with local and federal regulations.