Honeypot

How it works

A honeypot is instrumented end to end: every connection, request, authentication attempt and executed command is logged and raises an alert. Unlike an IDS or antivirus, which must separate malicious activity from a large volume of legitimate traffic, a honeypot carries no normal traffic at all. The detection logic is consequently binary and robust: interaction means the presence of an actor who should not be there, whether an external attacker, internal lateral movement or automated reconnaissance.

To be reached, a honeypot must be discovered by the adversary. It is therefore exposed in the areas attackers naturally explore, and clues are sometimes planted to lead them in:

• Breadcrumbs: stored credentials, configuration entries, network shares or command-history artifacts that quietly point toward the decoy.
• Honeytokens scattered across real assets, acting as portable bait that fires an alert the moment they are used.
• Realistic exposed services (SSH, RDP, SMB, databases, APIs) with credible banners and behavior to sustain the illusion.
• Placement aligned with likely attack paths, from the DMZ through the internal network to sensitive segments.

Types and network placement

Honeypots are traditionally classified by their level of interaction. A low-interaction honeypot emulates only the surface of a service: it answers a handful of requests, captures the first actions and carries little risk, but offers limited observational depth. A high-interaction honeypot exposes a real operating system or application, capturing the attacker's full behavior and tooling at the cost of a far greater compromise risk to be managed. The choice is a trade-off between intelligence richness and exposure.

Placement determines the value of the signal. At the perimeter or in the DMZ, a honeypot records scans and opportunistic probing from the internet. Inside the network, among production assets, it becomes a lateral-movement detector: an attacker already inside who maps the domain will eventually probe the decoy. The honeypot belongs to a broader family of deception lures alongside the decoy, the canary token and the honeytoken, which together cover files, credentials, services and entire hosts.

Detection value, intelligence and risks

The primary value of a honeypot is early, reliable detection: it often alerts before real damage occurs, in places where perimeter tools are blind. It also yields first-hand intelligence: source addresses, tested credentials, deployed tooling, and observed tactics and techniques, all feeding incident response and threat hunting. The concept dates back to foundational work in the 1990s, popularized by Lance Spitzner and the Honeynet Project, and remains a pillar of modern cyber-deception strategies.

The main risk lies in isolation. A poorly contained high-interaction honeypot can be hijacked by the attacker to pivot toward real systems. Strict network segmentation, continuous monitoring and outbound containment rules are therefore essential. A decoy that is too generic or badly maintained also risks being fingerprinted as fake, losing its credibility against a sophisticated adversary.

Honeypot, honeynet, honeytoken: what is the difference?

Cyber-deception vocabulary covers several neighboring concepts worth telling apart. The honeypot is a complete decoy system: a host or service that accepts connections and records everything that happens on it. A honeynet is an entire network of interconnected honeypots, usually operated for research to observe attack campaigns over time. The honeytoken is the finest-grained unit: a piece of trapped data (credential, API key, document, DNS record) that relies on no dedicated system but raises an alert the moment it is used.

The canary token is a popularized flavor of the honeytoken, often distributed as trapped files or URLs. The decoy is the umbrella term covering all of these artifices. A mature deceptive-security strategy layers them: honeypots to materialize credible targets, breadcrumbs to lead attackers toward them, and honeytokens scattered on real assets to cover what network decoys cannot see.

Honeypot vs EDR, IDS and SIEM

A honeypot does not replace an EDR, an IDS or a SIEM: it covers their blind spots. Those tools sift through massive volumes of legitimate activity looking for anomalies, which exposes them to two symmetrical pitfalls: false positives that drown analysts, and false negatives when a skilled attacker mimics normal behavior, disables the agent or operates from an uncovered host.

• An EDR watches the endpoints it is installed on; a honeypot detects activity across whole segments, including from agentless machines (IoT, OT, printers, network gear).
• An IDS relies on signatures and traffic analysis; a honeypot needs no signature at all, since any interaction is suspicious by construction.
• A SIEM correlates existing logs; a honeypot produces a native, very low-noise signal that sharpens exactly those correlations.
• Against lateral movement and internal reconnaissance, phases where perimeter tools are blind, the honeypot is often the first to alert.

In practice, SOC teams treat the honeypot as a high-fidelity tripwire: a honeypot alert almost always warrants immediate investigation, whereas the average EDR alert must first be triaged.

Use cases: SOC, SMB, MSSP and compliance

Honeypots serve very different profiles. For an established SOC, they provide a reliable internal-compromise signal and actionable intelligence (TTPs, tooling, tested credentials) that feeds threat hunting. For an SMB with no dedicated security team, a managed honeypot is one of the few ways to obtain credible intrusion detection without hiring analysts. For an MSSP, deception adds a differentiating detection layer that is cheap to supervise, since every alert is actionable by nature.

• Detecting lateral movement and internal reconnaissance after an initial compromise.
• Detecting insider threats: an employee or contractor exploring resources they have no reason to access.
• Reducing dwell time, the delay between intrusion and discovery, which still runs into weeks in most incidents.
• Supporting the incident-detection requirements of NIS2, ISO 27001 (A.8.16, monitoring) or DORA by demonstrating a measurable detection capability.
• Grounding red team and purple team exercises: a well-placed honeypot objectively measures operator stealth.

How to deploy a honeypot in your organization

An effective deployment follows a simple but rigorous path, from picking locations to wiring the alerts:

• Map the likely attack paths: server segments, user VLANs, DMZ, cloud environments, site-to-site links.
• Choose credible personas: a fake file server in the office VLAN, a fake database next to business applications, a fake admin appliance in the IT segment.
• Invest in realism: hostnames matching the internal naming convention, consistent banners and versions, plausible accounts and shares.
• Plant breadcrumbs and honeytokens on real assets to guide discovery of the decoys.
• Wire the alerts into existing channels: SIEM (Syslog, CEF, JSON), webhook, email or a SOAR platform, with a dedicated response runbook.
• Test the full chain under real conditions, for instance during a pentest or red team exercise, then revisit placement periodically.

The most common mistake is deploying a single, isolated honeypot in a segment nobody ever visits, then concluding that deception does not work. Coverage (several decoys, several segments) and credibility matter more than the sophistication of any single lure.

Open-source honeypots and commercial platforms

The open-source ecosystem is rich: Trapster Community (a modern multi-service honeypot in Python, with realistic website cloning and AI-assisted responses), Cowrie (SSH/Telnet), Dionaea (malware capture), OpenCanary (lightweight multi-protocol) or T-Pot (a distribution bundling dozens of honeypots with visualization). These tools are ideal for experimenting, learning and covering targeted needs.

Commercial deception platforms add what makes deception operable at organizational scale: centralized deployment and updating of decoys, honeytoken generation and tracking, dashboards, native SIEM/SOAR integrations and support. The right choice depends on team maturity: start with open source to validate the concept, then industrialize with a platform as the perimeter grows.

Frequently asked questions

Is a honeypot legal? Yes. Deploying a decoy on your own network is part of protecting your information system. It is not entrapment: the attacker acts on their own initiative, and the collected logs can support legal action.

Can an attacker detect a honeypot? A generic, badly configured decoy, yes. A realistic honeypot (consistent banners, credible behavior, plausible placement) withstands the usual checks; and even if identified, it has already done its job, since the alert fired at first contact.

How many honeypots should you deploy? The practical rule is coverage per sensitive network segment rather than an absolute number: every zone an attacker could move through deserves at least one decoy, complemented by honeytokens on real assets.

Do honeypots generate false positives? Very few. The only legitimate interactions come from internal vulnerability scanners and inventory tools, which are easily allowlisted. Everything else is an investigation signal.