There is a question that divides those who do security from those who only do it for show: is it worth lying to the attacker? The professional answer is yes, and it has been for a long time. The point is not the technology: it is the mathematics. A defender has to guess one thing — what is being protected — and guessing right means inventorying everything. An attacker has to understand everything in order to manage not to notice anything. An asymmetry in the defender’s favour, and deception technology exists to exaggerate it.
1986-1991: traffic as evidence
Cliff Stoll, 1986, is managing two systems on the connection to Los Alamos. He notices that line usage is suspicious: someone is browsing the print help of something that is not a user. The method is not an IDS: it is forensic economy. Anyone who downloads pages of print documentation consumes characters from the telephone line. Count the characters, divide by the average length of the pages, and you get the number of print jobs stolen. An indirect datum that becomes evidence.
In the same period, at Purdue University, Eugene Spafford designs — and will publish years later — what he himself describes as a possible first honeypot system with deception, designed to observe whoever believed they had found his main system. The 1991 intrusions he will document in his articles matter for one precise reason: they did not trigger any of the alarms then in existence. And they installed a backdoor engineered so that modified files still showed the previous CRC checksum, while the modification timestamps remained consistent.
It is a detail that dismantles many certainties: in 1991 an adversary’s ability to hide was already superior to the defenders’ ability to notice.
1991-1992: the night of Berferd
The other foundational text is by Bill Cheswick. An intruder, "Berferd", breaks into his system and the two of them spend the night playing. Cheswick describes it as a cage, and the name "honeypot" becomes established. In 1992 "an evening with berferd" is published, and the idea is publicised: the trap must not be hidden, it must be realistic enough not to arouse suspicion, and isolated enough not to be a risk.
From that moment the research branches:
Tools. After "Deceptive Toolkit" (1997, which plays the role of the aggressor as well) and "Cybercop Sting" (first commercial honeypot, 1998), tools such as dionaea (2003-2006, by Dino Welin) arrive, which emulates dozens of services and reacts to exploits, or KipZ and Cuckoo Sandbox, oriented towards automated analysis.
Theory. In 1999 Lance Spitzner formalises the key concepts — interaction level (how deep the deception must be) and realism (how real it must seem) — which are still today the grid by which a deception technology is judged. Later on, in 2003, the term honeytoken was also coined: the decoy object.
Why a token often beats a honeypot
A honeypot is a service: it has to be patched, monitored, protected. A honeytoken
is a datum: it costs a line of code and an alert rule. In real projects the
cost/benefit ratio is almost always in favour of the token, and the reason is
that the average automated attacker prefers the obvious target. A scanner
enumerating S3 buckets does not evaluate the contents: it finds
prod-backup-2024, downloads it, and the token does the rest.
The shape of the token also matters more than its type. Fake credentials with
plausible names, a Word file that really contains a document, an archive@
email address with an autoresponder: these are all things that have to withstand
a one-second glance. A honeytoken named token_test_123.txt is not a
honeytoken, it is noise.
Where we are today
Deception has moved from the server to the logical perimeter:
Dynamic microsegmentation. The most interesting concept: the honeypot is not a separate machine, it is a subnet or an instance created on purpose to be the only thing the attacker encounters after the initial compromise.
Automatic improvement. LLM-generated canary token variants that adapt name, size and content to the context of the system you want to protect, and therefore really do resemble what is around them.
Fake credential profiles. On cloud environments and identity providers, keys that resemble production ones are generated, with plausible service names. Using them triggers the alert before the escalation succeeds.
What to keep in mind
Deception does not replace the foundations: patching, segmentation, least privilege, logging. It works as a very low cost detector, and it is all the more useful the less visible you are. The day the attacker knows a honeypot network exists, the advantage thins out: from that moment the deception becomes a game you have to win every time.
This is why the practical rule is always the same: if you do not have a working alert channel, do not add tokens. A canary that nobody hears is worse than no canary at all, because it generates the conviction of being protected.