What Is Honeypot?

A honeypot is a system or resource deployed to be attacked. It has no legitimate purpose, so any interaction with it is suspicious by definition — which makes it one of the few detection mechanisms with essentially no false positives.

That property is the entire argument. In a field where alert fatigue is the dominant operational problem, a signal that is almost always real is unusually valuable.

Why the signal is so clean

Nobody has a reason to connect to a server that does not exist in any documentation, to use credentials that were never issued, or to open a file that was placed purely as bait.

Compare that with behavioural detection, which must distinguish malicious activity from legitimate administration and produces false positives constantly. The honeypot inverts the problem by removing legitimate activity entirely.

Internal placement is where the value is

Internet-facing honeypots see indiscriminate scanning, which is research material rather than detection. Internal ones see activity that has already got inside, which is the thing you actually want to know about.

An internal decoy touched by an internal system indicates lateral movement by something that should not be exploring. That is a high-confidence detection of the intrusion stage that is hardest to catch.

The lightweight versions are the practical ones

Full decoy systems require building and maintaining. The variants that deliver most of the value for almost no effort are smaller: credentials planted where an attacker would look, with alerting on any use. Documents that call home when opened. Directory accounts that nobody should ever authenticate as.

These take minutes to deploy, need no infrastructure, and produce the same near-zero false positive rate.

The risks, which are manageable

A decoy system that can be compromised and used to reach real infrastructure is a liability. Isolation has to be genuine, and high-interaction decoys — real operating systems with real services — carry the most risk and the most maintenance.

Low-interaction versions simulate just enough to detect and cannot be meaningfully compromised, which is why they are the sensible default outside research contexts.

It needs to be wired to a response

The alerting has to reach somebody, and the response has to be defined, because a honeypot detection is almost certainly real. Treating it with the same triage priority as a generic alert wastes the property that makes it worth deploying.

It also needs documenting internally, or an administrator will eventually find the decoy, investigate it as a rogue system and either remove it or trigger the alert themselves.

Logging, and the legal question

A decoy is also an intelligence source: what the intruder tried, which credentials they used, what tooling they brought. Capturing that turns a detection into indicators that can be searched across the estate.

The legal position is generally straightforward for internal decoys on systems you own, and it is worth a brief check where deception involves collecting data about identified individuals or deliberately encouraging activity. Internal documentation of what was deployed and why also protects against a colleague finding it and treating it as a rogue system.

Where to start

Create one account that nobody should ever use, place its credentials somewhere an attacker would find them, and alert on any authentication attempt. If it ever fires, you have learned something important.

See lateral movement. GuardsArm delivers managed security.