D3-CHN Connected Honeynet: Emulated Decoys Inside Your Network, Deployed Safely

An intruder inside the network scans, connects and tries logins on whatever answers, and most internal networks cannot tell that probing apart from normal traffic. D3-CHN Connected Honeynet is the MITRE D3FEND countermeasure for this: D3FEND defines it as "a decoy service, system, or environment, that is connected to the enterprise network, and simulates or emulates certain functionality to the network, without exposing full access to a production system". It sits in the Deceive tactic under the parent technique Decoy Environment, and D3FEND models it as something that spoofs the Local Area Network artefact. This card explains what makes a honeynet "connected" rather than integrated or standalone, which ATT&CK activity D3FEND relates it to, how to deploy and contain it, how to prove it fires, and where it fails. It is for detection engineers and network security teams; the hands-on build of individual honeypots is in the Honeypot deployment guide, which this page does not repeat.

Key takeaways

• Emulation, not production. A connected honeynet sits on the real LAN but only imitates services or parts of an operating system, so an attacker never gets a full production system.
• Every connection is suspicious. Nothing legitimate should talk to a decoy, so the alert threshold can be a single connection or login attempt once your own scanners are excluded.
• Fidelity is the trade-off. D3FEND notes it may not expose new attack patterns or zero-day exploits, but can be enough for specific known vulnerabilities and for discovery and credential-guessing activity.
• Being on the LAN is the risk. A decoy reachable from production can be reached from the decoy, so egress control and separate management are mandatory.
• Silent failure is common. Decoys stop reporting when an agent dies, a VLAN changes or a log forwarder breaks, so test the full alert path on a schedule.

D3-CHN at a glance

Connected, integrated or standalone

D3FEND splits decoy environments into three honeynet types by how they relate to production. The choice is mainly a trade between realism and the risk of giving an attacker a foothold.

For most enterprise detection programmes the connected honeynet is the starting point: it catches the discovery and lateral movement phase where internal intruders spend time, at a risk level that can be contained. See the D3-IHN Integrated Honeynet and D3-SHN Standalone Honeynet cards for the other two.

How it works

D3FEND's article is short: decoy honeypots are deployed within the enterprise that emulate certain services or portions of an operating system to attract attackers. The parent technique adds the operating principle: systems in a decoy environment have no legitimate business purpose, so any communication with them should be logged and analysed for indicators of compromise. In practice a connected honeynet has four parts.

• Decoy addresses: IP addresses in real server, user and management subnets, ideally with hostnames that follow your naming convention and records in internal DNS, so discovery tools find them.
• Emulated services: listeners that answer like a real service, for example SSH, RDP, SMB, HTTP admin pages, database logins or SNMP, presenting plausible banners and login prompts.
• Telemetry: each connection, login attempt (with username, and for some services the password tried) and request is logged and sent to the SIEM. The OpenCanary project, as one open-source example, documents syslog, email, HTTP webhook and file handlers for its alerts.
• Containment: the decoy host itself is locked down so that a compromise of the emulation cannot be used to reach production.

Commercial deception platforms automate the same pattern at scale: many decoy addresses served from few appliances, profiles that mimic the surrounding hosts, and central alerting. D3FEND's reference for this technique is an Acalvio Technologies patent on modifying a server to mimic a deception mechanism; D3FEND notes that citing a reference does not mean a product offers that functionality.

ATT&CK techniques D3FEND relates to D3-CHN

Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-CHN and no ATT&CK technique acts on its own artefact, Local Area Network (checked November 2026).

The one relationship D3FEND's site shows is inherited from the parent: Decoy Environment manages Decoy Artifact, and ATT&CK T1082 System Information Discovery is modelled as something that may access a Decoy Artifact. The table below gives that inferred row, then, labelled separately, the techniques that in NHI Mgmt Group's view a connected honeynet most often exposes in practice. The second group is our assessment, not a D3FEND mapping.

Defensive detail for these techniques is in T1082 System Information Discovery, MITRE ATT&CK T1046 Network Service Discovery, T1018 Remote System Discovery and MITRE ATT&CK T1110 Brute Force Guide.

Where identity fits

Login attempts are the richest signal a connected honeynet produces. A username tried against a decoy that no person or service should ever log in to tells you which account an intruder holds or is guessing. Service accounts and automation credentials are frequently harvested from scripts and configuration and then replayed across the network, so a decoy that records the account name gives an early lead for credential revocation. Pair the honeynet with decoy credentials planted on real hosts that point at the decoy, as described in D3-DUC Decoy User Credential.

Implementation steps

1. Write the goal. For example: "alert within 15 minutes on any internal scanning or login attempt in the server and management subnets" (example target, not a standard).
2. Choose placement. Put decoys where intruders look: server VLANs, jump host and management networks, and user subnets. One decoy per important subnet beats many in one place.
3. Choose service profiles. Match the neighbours: a Windows file server profile among Windows servers, a database profile in the data tier. Avoid offering every service on one host, which looks artificial.
4. Contain the decoy host. Deny all outbound traffic from the decoy except to the log collector and update source; manage it from a separate interface or network; run services without root where the software allows (OpenCanary's README documents dropping privileges after binding ports, and warns that its configuration file must be writable only by root); store no real data or credentials on it.
5. Register in DNS and inventory, carefully. A decoy invisible to discovery catches little. Give it a realistic name, but mark it in the CMDB as a decoy, visible only to the security team.
6. Connect alerting. Forward events to the SIEM with a dedicated rule and a high priority; enrich with source host owner and logged-on user.
7. Pilot and exclude. Run for two to four weeks. Vulnerability scanners, asset discovery and monitoring tools will hit decoys; exclude them by source address and schedule, and record each exclusion.
8. Roll back cleanly. To retire a decoy, remove its DNS records and addresses with the host, so stale names do not linger and later trigger confusion.

How to verify it works

• Connection test: from an ordinary workstation, connect to each decoy service on a schedule and confirm a SIEM alert arrives within the target time with correct source and decoy details.
• Login test: attempt a login with a test username and confirm the username is captured in the alert.
• Containment test: from the decoy host, attempt outbound connections to production and the internet and confirm they are blocked and logged.
• Discovery test: run your approved asset discovery from a non-excluded test source and confirm decoys appear as believable hosts.
• Heartbeat: alert when a decoy stops sending its own health or test events, so a dead decoy is noticed.

Limits, bypasses and failure patterns

• Fingerprinting: emulated services often differ from real ones in banners, timing or protocol edge cases. D3FEND states the trade-off directly: less sophistication than an integrated honeynet.
• Targeted movement: an intruder who reads the asset inventory or uses known hostnames may never scan, and so never touch a decoy.
• Exclusions as blind spots: broad exclusions for scanners or monitoring servers mean an attacker on those hosts is invisible to the decoys.
• Weak containment: a decoy with outbound access or shared management credentials can become a pivot point. Treat it as hostile once touched.
• Unwatched alerts: decoy events routed to a low-priority queue lose the main benefit, which is high-confidence early warning.
• Stale profiles: decoys that stay unchanged while the real estate is upgraded start to look out of place.

Framework mapping

For network monitoring that complements decoys, see the NDR Guide.

Practitioner checklist

• State the detection goal for each decoy subnet.
• Place decoys in server, management, jump host and user subnets.
• Match service profiles and hostnames to neighbouring systems.
• Block all decoy egress except logging and updates; separate management.
• Keep real data and real credentials off decoy hosts.
• Send every decoy event to the SIEM as a high-priority alert with enrichment.
• Exclude approved scanners narrowly and record each exclusion.
• Test connection, login, containment and heartbeat on a schedule.

Standards and references

• MITRE D3FEND: Connected Honeynet (D3-CHN)
• NIST: SP 800-53 Rev 5 Security and Privacy Controls (SC-26, SC-30)
• OpenCanary: Documentation
• OpenCanary: Project README
• MITRE ATT&CK: T1082 System Information Discovery

Related NHI Mgmt Group resources: Deception Technology Guide · Deception Technology Deployment Guide · Honeypot deployment · D3-DNR Decoy Network Resource · Lateral Movement Guide