What is Honeypot?

NIST SP 800-94 gives the reasoning in one line: honeypots are hosts with no authorized users other than their administrators, because they serve no business function, so all activity directed at them is considered suspicious. The same 2007 guide calls them a supplement to intrusion detection rather than a replacement, and says qualified incident handlers and intrusion detection analysts should manage them. MITRE D3FEND files them under Decoy Environment, hosts and networks built to deceive an attacker, and sorts deployments by how they connect to production. An integrated honeynet places decoys inside the production environment. A connected one attaches to the enterprise network and emulates functionality without exposing a real production system. A standalone one has no connection to production at all.

Interaction level is the other axis. A low-interaction honeypot emulates a service just far enough to record the attempt. OpenCanary, from Thinkst, is a Python daemon that answers on common network protocols and sends an alert when something interacts with it; its documentation names the main use as catching attackers after they have breached non-public networks, and it runs on hardware as small as a Raspberry Pi. A high-interaction honeypot hands the attacker a real system, which shows you their tools and hands-on-keyboard behavior at the cost of real risk. Cowrie sits between the two for SSH and Telnet. Its default shell mode is medium interaction: it emulates a UNIX system in Python and logs brute-force attempts and the shell commands the attacker types; in proxy mode, which is high interaction, it relays the session to another system and records what the attacker does there.

Honeytokens move the same idea from machines to data: a credential, file, key or record that nobody legitimately uses, planted where an intruder will find it. D3FEND calls the credential version a Decoy User Credential and attaches two conditions. A stolen decoy credential should lead into a monitored decoy environment, and the setup needs continuous maintenance to stay believable. Microsoft Defender for Identity lets you tag users and devices as honeytokens; its documentation describes them as usually dormant accounts where any sign-in triggers an alert. Thinkst's free Canarytokens apply the idea to files and cloud secrets, such as a Word document, a DNS name or a set of AWS API keys that raise an alarm when someone opens or uses them.

On Windows, a honeytoken account surfaces in the domain controller's Security log, and Microsoft's monitoring guidance for events 4768 and 4776 includes watching for accounts that should never be used. Which event you get depends on how the credential is tried. A Kerberos ticket request logs 4768 on the domain controller, with Result Code 0x0 when the ticket is issued. A wrong password over Kerberos logs 4771 (Kerberos pre-authentication failed) instead, because 4768 is not generated for result code 0x18. An NTLM attempt logs 4776 on the domain controller with the account name, the source workstation and an error code, 0xC000006A for a bad password. A failed logon on a member server also leaves a 4625 on that server.

Here is how that reads in a queue (simulated example generated by SOCSimulator Research; names and addresses are invented). The decoy is svc-sqlbak2, a service account with no group memberships of interest and no logon history, whose password sits in an old deployment script on a file share. At 09:41 the domain controller logs:

4776 | Computer DC02.corp.example | PackageName MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 | TargetUserName svc-sqlbak2 | Workstation WS-FIN-022 | Status 0xc000006a

Four minutes later:

4768 | Computer DC02.corp.example | TargetUserName svc-sqlbak2 | ServiceName krbtgt | Status 0x0 | PreAuthType 2 | IpAddress ::ffff:10.20.30.41

The first line is a wrong guess over NTLM from WS-FIN-022, likely part of a spray across many accounts. The second is a successful ticket request, which means someone now holds the real password, and the only place that password existed was the script. Two questions follow. Is 10.20.30.41 the same machine as WS-FIN-022 (DHCP or the EDR inventory will tell you)? And who read that share? If file share auditing is on, it can name the reader. Either way, someone has been through your file shares, and the investigation starts there.

Decoys bring risks of their own. Attackers fingerprint them: Vetterl and Clayton (USENIX WOOT 2018) identified low- and medium-interaction honeypots with a single packet, because the off-the-shelf libraries they use implement protocols slightly differently from the systems they imitate. Their Internet-wide scans found 7,605 instances across nine implementations, and 27% of the SSH honeypots had not been updated in the previous 31 months. A decoy with default banners and hostnames tells an intruder where not to go. A high-interaction honeypot is a real machine under an attacker's control, so its isolation and outbound filtering decide whether it becomes a launch point against someone else. NIST's 2007 guide also warned that the legality of honeypots had not been clearly established and advised organizations to study the legal side before deploying one.

Most of the noise on an internal decoy comes from your own tools. Vulnerability scanners, asset discovery and monitoring probes touch every address they can reach, decoys included. Exclude them by source address and schedule, and treat a scanner touching the decoy outside its window as an alert in its own right.