Hard2bit
← Back to glossaryDetection and response

Honeypot

What a honeypot is

A honeypot is a decoy system deliberately deployed inside a network to attract an attacker's attention, observe their techniques and trigger early alerts. It looks like a legitimate asset (server, database, web application, IoT device) and has no real operational use, so any interaction with it is anomalous by definition. If an attacker or malicious process touches the honeypot, the organization knows immediately that something is happening. It is one of the oldest deception techniques in cybersecurity and remains one of the most effective because its false-positive rate is essentially zero.

Why it matters

Honeypots are one of the few security signals that come close to 100% precision. Almost no one has a legitimate reason to connect to a fake server buried in the internal network, attempt login on a decoy database or touch a share with a tempting name. That is why an alert from a honeypot is among the most reliable signals a SOC can receive. They shine at detecting lateral movement in already-compromised networks, where attackers explore the environment and decoys look as attractive as real assets. For an organization aiming to meet detection requirements under NIS2 or to demonstrate threat-hunting capability under DORA, honeypots are a tactical tool with excellent cost-benefit.

Key points

Three interaction levels: low (emulates basic services, detects scans), medium (simulates login and basic response) and high (full operating system in a sandbox, allows in-depth study of attacker behavior).

Honeypot ≠ honeytoken. A honeytoken is a decoy credential, file or database entry: no one should use it, so its use triggers an alert. They tend to be easier to deploy than full honeypots.

Internal deployment (T-pot, Cowrie, Honeytrap, commercial solutions like TrapX or Thinkst Canary) versus external (sensors in cloud providers for global threat intelligence). For defense, internal is what matters; for intelligence, external.

Honeypot + SIEM + threat hunting is the combination that delivers the most ROI: the honeypot produces the signal, the SIEM correlates it with the rest of the environment and the hunting team investigates the scope of the compromise.

Example: honeypot detecting internal lateral movement

An organization deploys three honeypots in different internal VLANs: a server that looks like an old database with a tempting name ("oracle-finance-2018"), an SMB share that looks like an HR backup, and an endpoint that looks like a senior executive's workstation. None has operational use. Months later, an attacker with a foothold on a compromised endpoint moves laterally looking for valuable assets. They detect the honeypots via network enumeration, attempt to connect to the supposed "oracle-finance-2018" using default credentials and immediately trigger a SOC alert. Since no one has legitimate reason to touch that server, the alert is near 100% precise. The SOC isolates the origin endpoint via EDR, identifies that the attacker has been inside for three weeks and launches incident response. Without honeypots, that internal reconnaissance would have stayed invisible.

Common mistakes

  • Deploying honeypots without informing the SOC or the network team. When an alert fires, someone has to know what it is and how to investigate. Honeypot without process = ignored noise.
  • Honeypots that are too obvious. A server named 'honeypot-01' fools no one. Convincing the attacker requires realistic names, plausible configuration and credible background traffic.
  • Honeypots too exposed to the outside without segmentation. If the decoy is compromised and can reach the rest of the environment, instead of defense it becomes a pivot for the attacker.
  • Not combining with honeytokens. Honeytokens are extremely cheap (fake credentials in a password manager, intriguingly named files in a share, decoy records in a database), add coverage and require almost zero maintenance.

Related services

This concept may relate to services such as:

Frequently asked questions

What's the difference between honeypot and honeytoken?

A honeypot is a full decoy system (server, application, device). A honeytoken is a smaller element: a fake credential in a password manager, a tempting file in a share, a fake entry in a database. Honeytokens are cheaper to deploy and maintain; honeypots are more complete for studying attacker techniques.

Are honeypots legal?

Yes, on the organization's own networks. Legal nuances appear when seeking active attribution or interacting with the attacker (in some countries, 'entrapment'). As a passive defensive tool inside your own environment they are perfectly legal and GDPR-compatible if they don't accidentally collect personal data from legitimate users.

How much maintenance does a honeypot require?

It depends on the type. Low-interaction honeypots and honeytokens are very cheap: once deployed, they need little beyond reviewing alerts. High-interaction ones consume more resources (they must simulate convincing real systems) and provide deeper intelligence. Most organizations start with honeytokens and low-interaction honeypots.