November 5, 2026
Updated: November 11, 2026
How decoys and honeytokens catch reconnaissance and lateral movement, which type fits which goal, and how to run them without new risk.
Mohammed Khalil
What is a honeypot? It is a decoy system, account, file or credential that has no legitimate business use, so any interaction with it is a strong sign of an intruder, a curious insider or a misconfiguration. Security teams use honeypots, and smaller decoys called honeytokens, to catch reconnaissance and lateral movement early, to study attacker behavior and to waste an adversary's time. NIST defines a honeypot as a system or resource designed to attract intruders, and MITRE D3FEND catalogs it as a decoy environment. A honeypot adds detection; it never replaces patching, logging or endpoint protection.
The NIST glossary, quoting CNSSI 4009-2022 and IETF RFC 4949, defines a honeypot as a system or system resource, such as a web server or a file on a server, that is "designed to be attractive to potential crackers and intruders." MITRE's defensive knowledge base, D3FEND, lists the same idea as a Decoy Environment (D3-DE), with "honeypot" as its synonym.
The principle that makes a honeypot useful fits in one sentence. D3FEND describes decoys as configured so that some means of communication has no legitimate business purpose, and any communication through it should be logged and analyzed. Real users have no reason to log in to a fake file server, open a fake password spreadsheet or request a ticket for a service nobody runs. When that happens, the alert is worth reading.
That is the main difference from most detection tools. An intrusion detection system or an EDR agent watches legitimate activity and tries to spot the bad part. A decoy watches nothing legitimate at all, so it starts with very little noise.
These terms are often used loosely. Here is how they relate.
| Term | What it is | Example |
|---|---|---|
| Honeypot | A decoy host or service that an attacker can connect to | A fake SSH server or file server on an internal network |
| Honeynet | A network of honeypots built to look like a real environment | Several decoy servers, a fake domain controller and fake users on an isolated segment |
| Honeytoken | A decoy piece of data rather than a whole system | A fake credential, document, API key, database row or service account |
| Deception technology | Products and programs that deploy and manage decoys at scale | A platform that places decoy hosts, credentials and files across an estate and routes alerts to the SOC |
| Adversary engagement | Using deception on purpose to detect, delay and learn from adversaries | Planned operations described in the MITRE Engage framework |
MITRE Engage, MITRE's framework for adversary engagement, makes a point worth repeating: "Deception is a process, not a fire-and-forget technology stack." Its matrix groups activities under three goals: Expose (detect and collect), Affect (prevent, direct and disrupt) and Elicit (reassure and motivate). Lures, Introduced Vulnerabilities, Pocket Litter and Isolation are among the listed activities. MITRE says that across nine elicitation operations it ran, it collected on average about 40 new pieces of intelligence per operation with adversary engagement, against about two indicators of compromise before.
NIST treats decoys as a security control too. In NIST SP 800-53 Rev. 5, control SC-26 "Decoys" (named "Honeypots" in Revision 4) calls for components designed to be the target of attacks for "detecting, deflecting, and analyzing" them, and its guidance says decoys need isolation measures and may need a review by general counsel before deployment.
Every honeypot or honeytoken has the same three parts:
Most failed deployments miss the third part. A decoy that fires into a log nobody reads detects nothing. The UK National Cyber Security Centre made the same point after its trials: without a clear strategy, organizations "risk deploying tools that generate noise rather than insight" (NCSC, December 11, 2025).
Honeypots are usually classified two ways: by how much an attacker can interact with them, and by why they are deployed. Honeytokens sit at the light end of the scale.
| Type | What it emulates | What you learn | Effort | Risk if misconfigured |
|---|---|---|---|---|
| Low interaction | A few services or banners; no real operating system behind them | Who connected, from where, when and to which port | Low; quick to deploy and maintain | Low, but easy for scanners to fingerprint |
| Medium interaction | A convincing shell or protocol (for example an emulated SSH login) without a full system | Credentials tried, commands typed, files downloaded | Moderate | Moderate; emulation gaps can be detected |
| High interaction | Real operating systems and applications, often in virtual machines | Full attacker tooling, techniques and objectives | High; needs constant monitoring | High; a compromised decoy can be used to attack others unless contained |
Low-interaction honeypots are the usual choice inside companies because they are cheap and safe. High-interaction honeypots belong mainly to research teams that can watch them around the clock. Medium-interaction tools such as the open-source Cowrie SSH and Telnet honeypot sit in between.
D3FEND adds a placement view. An integrated honeynet (D3-IHN) puts decoys inside the production environment. A connected honeynet (D3-CHN) is joined to the enterprise network but emulates functions without exposing production systems. A standalone honeynet (D3-SHN) has no connection to production at all.
| Production honeypot | Research honeypot | |
|---|---|---|
| Goal | Detect attacks against this organization | Learn how attackers and malware behave in general |
| Typical placement | Inside the corporate network, near valuable assets | Internet-facing or on dedicated research networks |
| Typical interaction level | Low, or honeytokens | Medium to high |
| Who runs it | SOC and detection engineering teams | Universities, CERTs, threat intelligence teams, governments |
| Main output | High-fidelity alerts | Malware samples, attacker techniques, trend data |
| Main risk | Alert fatigue if poorly placed | Being used as a launch point if containment fails |
Most organizations only need production decoys. An internet-facing research honeypot attracts constant automated scanning, which is useful for researchers but rarely tells a company anything about its own exposure.
Honeytokens are the cheapest and often the most effective form of deception, because they go where attackers already look. D3FEND groups them under Decoy Object (D3-DO), with subtypes such as Decoy File (D3-DF), Decoy User Credential (D3-DUC), Decoy Network Resource (D3-DNR) and Decoy Session Token (D3-DST).
The research behind them is not new. In 2009, Columbia University researchers described decoy documents that contain bogus credentials and hidden beacons that signal when and where a file is opened, aimed at insiders who exfiltrate data. In 2013, Ari Juels and Ronald Rivest proposed honeywords: false passwords stored next to each real password hash, so that an attacker who cracks a stolen hash file and logs in with a honeyword sets off an alarm.
The table below is a selection guide for the most common decoy objects.
| Decoy | What it looks like | Where to place it | What triggers the alert | Common false-positive source |
|---|---|---|---|---|
| Honey credential | A username and password in a script, config file, browser store or memory | Admin workstations, jump hosts, file shares, code repositories | Any authentication attempt with that account | Old scripts or backup jobs that scan for credentials |
| Honey user account | A dormant domain account with an attractive name | Active Directory, identity provider | Any sign-in or password reset | Account cleanup jobs |
| Honey SPN | A fake service account with a service principal name that no real service uses | Active Directory | Any Kerberos service ticket request for that SPN | Security scanners and audit tools that enumerate SPNs |
| Canary file | A document such as "passwords.xlsx" or "board-salaries.docx" | File shares, SharePoint, executive folders | File open, copy or a callback from the document | Backup, indexing and antivirus software reading the file |
| Decoy cloud key | An access key with no permissions | Code repositories, CI variables, developer laptops | Any API call made with the key | Secret scanners that test keys |
| Decoy host or share | A server or share with a believable name | Server VLANs, near crown-jewel systems | Any connection, login or port scan | Vulnerability scanners and inventory tools |
Two practical notes. First, every decoy needs an exclusion list for your own scanners, backups and inventory tools, or it will train the SOC to ignore it. Second, products can help. Microsoft documents a honeytoken tag in Defender for Identity for users and devices, and says any sign-in from a honeytoken account triggers an alert.
A honey SPN targets one of the most common attacks in Windows domains. In Kerberoasting (MITRE ATT&CK T1558.003), any authenticated domain user can request Kerberos service tickets for accounts that have a service principal name, then try to crack the ticket offline to recover the service account's password. ATT&CK's detection guidance focuses on unusual ticket requests, logged on domain controllers as Windows event 4769.
A honey SPN turns that noise into a clear signal. You create a service account that no real service uses, give it an SPN and a very strong password, and alert on any 4769 event that names it. Legitimate clients never ask for that ticket, so a request usually means someone is enumerating SPNs and requesting tickets in bulk. Our internal penetration testing guide explains in its Kerberoasting section how testers find and exploit weak service accounts, which is exactly the behavior this decoy is meant to catch.
Illustrative scenario (not a real incident). A contractor laptop is compromised by phishing. The intruder lists service accounts in Active Directory and requests tickets for all of them, including "svc-sqlbackup", a honey SPN. The domain controller logs event 4769 for that account, the SIEM raises a high-severity alert within minutes and the SOC isolates the laptop before any real password is cracked. The decoy did not stop the attack; it turned a quiet credential-access step into an early, unambiguous alert.
Decoys work best at the stages of an intrusion where an attacker has to explore. Once inside, an intruder does not know which servers are real, which credentials work or which files matter, so they look around. That is where decoys sit. The map below uses tactic names from the MITRE ATT&CK framework.
| Attacker behavior | ATT&CK tactic | Decoy that catches it | Signal |
|---|---|---|---|
| Scanning the network for live hosts and services | Reconnaissance and Discovery | Low-interaction honeypot on unused internal IP addresses | Connection or port scan against an address nobody uses |
| Browsing file shares and searching for sensitive files | Discovery and Collection | Canary file or decoy share | File opened, copied or beacon fired |
| Harvesting passwords from memory, scripts or browsers | Credential Access | Honey credential | Login attempt with the decoy account anywhere |
| Requesting service tickets to crack offline | Credential Access | Honey SPN | Event 4769 for the decoy SPN |
| Moving to other machines with stolen credentials | Lateral Movement | Decoy host plus honey credentials | Login or remote session on the decoy host |
| Testing stolen cloud keys | Discovery and Credential Access | Decoy cloud key | Any API call with the key |
| An insider looking where they should not | Collection | Canary file in restricted folders | File opened by an account with no business need |
Lateral movement is the stage where decoys add the most. Attackers moving between machines often use valid accounts and built-in admin tools, which look like normal administration to many controls. A login to a host that should never receive logins does not. Reconnaissance on the internal network is the other strong case, because ATT&CK's Discovery tactic (TA0007) is hard to separate from IT activity, while a scan that touches a decoy address is not.
Decoys can also help with insider risk, as the Columbia decoy document research and several NCSC trial participants noted, but only when placed in folders that an insider would have no business opening.
A decoy must never become a weak point. NIST's SC-26 guidance says decoys need supporting isolation so that deflected malicious code does not infect real systems. The NCSC lists misconfiguration as a real risk: a badly set up deception tool can fail to detect threats, create false confidence, or "create openings for attackers".
Honeypots raise three legal questions in the United States: privacy, entrapment and liability. This section is general information, not legal advice. Get counsel to review any honeypot that captures communication content, as NIST SC-26 suggests.
| Issue | What it means | Practical step |
|---|---|---|
| Privacy and interception | Capturing the content of communications can fall under the federal Wiretap Act. Its provider exception, 18 U.S.C. 2511(2)(a)(i), allows a service provider's staff to intercept communications when necessary to protect the provider's rights or property. | Run decoys on your own systems for protection purposes; log metadata only where content is not needed; ask counsel before capturing content |
| Entrapment | Entrapment is a criminal defense against government inducement. A privately run, passive decoy that an intruder finds on their own is generally not entrapment. | Do not advertise or invite attacks; keep decoys passive |
| Liability for downstream harm | If a high-interaction honeypot is compromised and used to attack a third party, its operator may face liability questions. | Block outbound traffic from decoys; prefer low interaction and honeytokens |
| Data protection outside the U.S. | Under EU law, IP addresses can be personal data, so honeypot logs may fall under data protection rules. | Set retention limits and a lawful basis for logs where EU law applies |
The provider exception is in the Wiretap Act at 18 U.S.C. 2511(2)(a)(i). For background, the SANS Institute published a primer on US laws related to honeypot deployments covering privacy and entrapment, and an academic review of honeypot privacy under EU law explains the IP-address point.
On entrapment specifically, a concern is often raised that a honeypot "tricks" people into crime. Production decoys inside your own network are found by someone who is already exploring without permission, and private organizations are not the government. The bigger legal risks are what you record and what a compromised decoy might do.
Red teams and penetration testers meet decoys more and more often, and how they react is useful data for defenders.
The largest published study on this question is the Tularosa study, run by the U.S. Department of Defense and Sandia National Laboratories and presented at HICSS in 2019. Over 130 professional red teamers performed a network penetration task while researchers controlled whether decoy systems were present and whether participants were told that deception might be in use. A 2021 follow-up analysis found that the combination of decoys and telling attackers about them had the greatest effect on attack behavior compared with a control group.
The NCSC reached a similar view from academic research: attackers who believe deception is in use are less confident. Yet 90% of trial participants said they would not publicly announce that they use it.
Research also shows the other side. University of Cambridge researchers in the 2018 Bitter Harvest paper fingerprinted low- and medium-interaction honeypots across the internet with a single packet and found 7,605 honeypot instances across nine implementations. They also found that 27% of the SSH honeypots had not been updated in 31 months. Skilled operators, real or simulated, can spot cheap or stale decoys.
For defenders, this suggests a simple approach: treat your deception like any other control and test it.
A red team engagement is the most realistic test, because it measures whether a capable adversary pursuing a goal trips your decoys and whether your team responds in time.
Honeypots are useful, but they have real limits that buyers and SOC leads should plan for.
For a team that has never used deception, a small, well-wired start beats a large, noisy one.
| Week | Action | Done when |
|---|---|---|
| 1 | Pick two detection goals, such as SPN enumeration and share browsing, and get sign-off from the SOC lead and counsel | Goals, owners and legal review recorded |
| 2 | Deploy one honey SPN and one honey credential, plus a canary file in a sensitive share | Decoys live with no privileges and exclusions set |
| 3 | Build SIEM rules and a playbook, then trigger each decoy yourself in a controlled test | Every decoy produces a high-severity alert that reaches an analyst |
| 4 | Ask a red team or penetration tester to include the environment in scope and report which decoys they hit | Detection and response times recorded; gaps fixed |
After the first month, expand only where a decoy proved its value, and add low-interaction decoy hosts on unused internal addresses if network discovery is a gap.
People search for "honeypot" with other meanings in mind, and this guide does not cover them in depth.
A honeypot is a fake system, account or file that looks real but has no legitimate use. Because nobody should touch it, any access is a strong sign of an attacker, an insider or a misconfiguration, so security teams use it as an early warning.
A honeypot is a decoy system or service that an attacker can connect to. A honeytoken is a decoy piece of data, such as a fake password, document, API key or service account, that triggers an alert when someone uses it.
In the United States, running a passive decoy on your own network for security purposes is generally lawful. The main questions are privacy rules if you capture communication content and liability if a compromised decoy harms others. Ask counsel before capturing content or deploying high-interaction honeypots.
Generally no. Entrapment is a defense against government inducement to commit a crime. A private organization's passive decoy that an intruder finds while exploring without permission does not induce the crime.
Yes, sometimes. Research has fingerprinted thousands of low- and medium-interaction honeypots on the internet, and experienced testers watch for decoys. Realistic, well-maintained decoys and honeytokens placed where attackers must look are much harder to spot.
No. Honeypots detect and slow attackers and can reveal their methods, but they do not fix the weaknesses being exploited. They work alongside patching, identity hardening, logging and endpoint detection.
In crypto, a honeypot is a scam token or smart contract built to look profitable or exploitable while hiding a trap that keeps the victim's funds, for example by blocking sales.
A honeypot is only as good as the alert it produces and the response that follows. Pick one or two decoys from the selection table, deploy them with the safety checklist, and then find out whether they catch a realistic attacker.
DeepStrike's red teaming services include detection validation, measuring your SOC, alerting and response workflows against realistic tradecraft, which is the test a deception program needs. If you want to start with a scoped assessment of your internal network and Active Directory, see our penetration testing services, or contact our team to discuss scope.
Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.
Stay secure with DeepStrike penetration testing services. Reach out for a quote or customized technical proposal today
Contact Us
