A honeynet that shares nothing with production is the safest deception environment to run, but its isolation is also why attackers inside your network may never find it. MITRE D3FEND names this countermeasure Standalone Honeynet (D3-SHN) and defines it as "An environment created for the purpose of attracting attackers and eliciting their behaviors that is not connected to any production enterprise systems." It sits under the Deceive tactic as a child of Decoy Environment (D3-DE), next to Connected Honeynet (D3-CHN) and Integrated Honeynet (D3-IHN). This card explains what makes a honeynet standalone, what it is good for (internet-facing threat collection, malware detonation, research), how to keep it isolated, and how to prove that isolation and monitoring both hold. It is written for detection engineers and threat intelligence teams. Honeypot selection and general placement are covered in Honeypot deployment and are not repeated here.
Key takeaways
- Standalone means no interaction with enterprise resources. D3FEND says the honeynet may sit near or inside part of the enterprise address space but does not interact with enterprise systems. No shared directory, credentials, storage or management plane.
- Lower risk, lower fidelity. D3FEND's own considerations: a standalone honeynet is lower risk than connected or integrated honeynets, at the cost of realism, and significant extra effort is needed to make it look real.
- Best for outside-in intelligence. Internet-facing standalone honeynets collect scanning, brute force and exploitation attempts, plus malware samples, without exposing production. They are a weaker tool for catching an intruder already inside.
- Isolation must be tested, not assumed. The honeynet will be compromised by design. Verify regularly that nothing in it can reach production and that its outbound traffic is limited.
- ATT&CK coverage is thin and inferred. D3FEND relates D3-SHN only to System Information Discovery (T1082), through the decoy artefacts and spoofed intranet it presents.
D3-SHN at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-SHN (d3f:StandaloneHoneynet) |
| Tactic | Deceive |
| Parent technique | Decoy Environment (D3-DE), which manages decoy artefacts |
| Digital artefact | Intranet Network (D3FEND relation: spoofs Intranet Network) |
| D3FEND reference | Palo Alto Networks patent US9882929B1, virtual clones for detonation within a honey network |
| Connection to production | None |
| Typical uses | Internet sensor networks, malware detonation, attacker tooling research, training |
| Main limitation | Low realism and little chance of being reached by an attacker already inside |
How it differs from connected and integrated honeynets
D3FEND splits honeynets by how they relate to the real enterprise. Choosing among them is a risk and fidelity trade-off; the risk and realism columns follow D3FEND's considerations for D3-SHN.
| Technique | Relation to production | Risk to production | Realism | Fits when |
|---|---|---|---|---|
| Standalone Honeynet (D3-SHN) | None; may sit in nearby address space | Lowest | Lowest; must be built by hand | You want threat data or samples and cannot accept any path into production |
| Connected Honeynet (D3-CHN) | Decoy services or systems connected to the enterprise network, emulating functions without exposing a production system | Higher than standalone | Higher | You want to catch internal lateral movement with dedicated decoy segments |
| Integrated Honeynet (D3-IHN) | Decoys set inside the production environment | Higher than standalone | Higher | You have mature deception operations and strong egress control |
For catching intruders inside the network, decoy credentials and files that lead to monitored decoys usually give more value per effort. See D3-DUC Decoy User Credential and D3-DF Decoy File.
ATT&CK techniques D3FEND relates to D3-SHN
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-SHN. Its site shows one inferred, experimental relationship, derived because D3-SHN spoofs an Intranet Network and manages Decoy Artifacts (D3FEND 1.6.0, checked November 2026). The ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | Relation | What the honeynet observes |
|---|---|---|---|
| T1082 | System Information Discovery | Inferred via spoofed intranet and decoy artefacts | The commands and tooling an attacker uses to profile a host once inside the decoy |
In practice a standalone honeynet records much more than discovery: login attempts, exploitation, payload downloads and command and control traffic. Those observations feed detection content, but D3FEND does not map them, so this card does not claim them as coverage.
Where it is implemented
| Implementation class | What it provides | Example from documentation |
|---|---|---|
| Multi-honeypot platforms | Many emulated services on one host or a distributed set, with central logging and dashboards | T-Pot (GPL-3.0) bundles 20+ honeypots on Docker with the Elastic Stack and Suricata; its documentation asks for 16 GB RAM and 256 GB SSD for a hive (full) install and an unfiltered internet connection |
| Single-protocol honeypots | Deep emulation of one protocol | Cowrie, an SSH and Telnet honeypot that logs brute force attempts and shell interaction to JSON, records sessions for replay and saves downloaded files |
| Detonation honey networks | Virtual clones of real hosts that run suspicious content in an instrumented environment | The D3FEND-referenced Palo Alto Networks patent describes cloning a target host's profile and detonating samples in the clone, with behaviour and network activity logged |
| Cloud-hosted sensors | Disposable honeypot instances in a separate cloud account or subscription | Any of the above, deployed in an account with no trust to production accounts |
Implementation steps
- Write down the purpose. Threat intelligence on internet scanning, sample collection, or research. The purpose decides which services to emulate and how long to keep data.
- Build separation first. Use separate hardware, a separate cloud account or a dedicated hypervisor host; no shared identity provider, no joined domain, no shared backups, storage or monitoring agents that phone home to production consoles. NIST SP 800-53 SC-7(13) describes isolating security tools in physically separate subnetworks with managed interfaces.
- Control outbound traffic. Allow only what the honeynet needs for logging and updates (T-Pot, for example, documents outbound 80 and 443) and rate-limit or block everything else, so a compromised decoy cannot be used to attack third parties. This is the main residual risk of any honeynet.
- Ship logs one way. Send events to a collector the honeynet cannot query back into. T-Pot keeps management on high ports (SSH 64295, web 64297) and its documentation says to restrict ports above 64000 to trusted IPs.
- Decide on data sharing. T-Pot sends captured data to a community backend by default through its ewsposter service; its documentation explains how to remove that section if your policy does not allow sharing.
- Add realism where it matters. D3FEND warns that standalone honeynets need significant effort to look real. Use plausible host names, banners and file content, and avoid default honeypot fingerprints.
- Pilot and retire cleanly. Run first in a lab VM, as the T-Pot documentation advises, then expose. To retire, revoke any keys used for log shipping, destroy the hosts and keep captured data only as long as the purpose requires.
How to verify it works
- Isolation test: from inside each honeynet host, attempt to reach production subnets, the identity provider and management consoles. Every attempt should fail and be logged. Repeat after every network change.
- Egress test: confirm that outbound connections other than the allowed logging and update paths are blocked or rate-limited.
- Capture test: from an approved external host, run a failed SSH login and a simple web request against the honeynet and confirm both appear in the central log store within the expected time.
- Credential test: confirm no production credential, certificate or API key exists on any honeynet host. A standalone honeynet must hold nothing an attacker could reuse.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Isolation tests passed | 100% each quarter | The core safety property of the technique |
| Hours of log gaps per month | Close to zero | A silent sensor gives false comfort |
| Indicators or detections produced from honeynet data | Tracked per quarter | Shows the data is used, not just stored |
| Production secrets found on honeynet hosts | Zero | Prevents the decoy becoming a real foothold |
Limits, bypasses and failure patterns
- Isolation drift: a later firewall change, a shared jump host or an endpoint agent reporting to the production console quietly turns a standalone honeynet into a connected one.
- Honeypot fingerprinting: default banners and emulation quirks let attackers and scanners recognise common honeypots and skip them.
- Abuse as a launch point: without egress control, a compromised honeynet host can scan or attack others.
- Wrong question: a standalone honeynet on the internet tells you who is scanning everyone; it will rarely tell you that your own network is breached.
- Data without an owner: large volumes of honeypot events with no analyst or detection engineering use.
- Sensitive data on decoys: T-Pot's documentation warns not to store sensitive data on honeypots and says compromise cannot be ruled out.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-26 Decoys | Components designed to be the target of attacks for detecting, deflecting and analysing them |
| NIST SP 800-53 Rev 5 | SC-44 Detonation Chambers | Detonation use of a honey network |
| NIST SP 800-53 Rev 5 | SC-7(13) Isolation of Security Tools, Mechanisms, and Support Components | Keeping the honeynet in separate subnetworks with managed interfaces |
| NIST CSF 2.0 | DE.CM-01, DE.AE-02 | Network monitoring and analysis of adverse events |
| MITRE D3FEND | D3-DE, D3-SHN | Parent and technique |
Practitioner checklist
- State the purpose of the honeynet before building it.
- Host it on separate infrastructure or a separate cloud account with no trust to production.
- Keep production credentials, agents and management consoles off every honeynet host.
- Allow only logging and update egress; block or rate-limit the rest.
- Restrict management ports to trusted addresses.
- Decide and document whether captured data is shared externally.
- Change default banners and host names to reduce fingerprinting.
- Run isolation, egress and capture tests on a schedule and after network changes.
- Route honeynet findings into detection engineering and threat intelligence work.
Standards and references
- MITRE D3FEND: Standalone Honeynet (D3-SHN)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-26, SC-44)
- Google Patents: US9882929B1, virtual clone for detonation within a honey network
- Telekom Security: T-Pot documentation
- Cowrie: documentation
- MITRE ATT&CK: T1082 System Information Discovery
Related NHI Mgmt Group resources: Honeypot deployment · Deception Technology Deployment Guide · Deception Technology Guide · MITRE D3FEND Guide