An integrated honeynet gives defenders the fullest view of an intruder's behaviour of any decoy design, because the decoys are real systems on the production network, and for the same reason it is the riskiest to run. MITRE D3FEND names this countermeasure Integrated Honeynet (D3-IHN) and defines it as "The practice of setting decoys in a production environment to entice interaction from attackers." It sits under the Deceive tactic as a child of Decoy Environment (D3-DE), alongside Connected Honeynet (D3-CHN) and Standalone Honeynet (D3-SHN). This card explains what makes a honeynet "integrated", what D3FEND does and does not map it to, how to build one with the containment and capture controls it needs, and how to prove it still works. It is written for detection engineers and SOC architects who have already read the Honeypot deployment guide and are considering high-interaction decoys inside production.
Key takeaways
- Full interaction, full risk. D3FEND describes integrated honeynets as full production environments connected to the enterprise network that allow full interaction and a complete view of an attack. The attacker gets real systems to work with.
- D3FEND names three risks. An attacker who controls a decoy may attack connected hosts, may eavesdrop on network traffic, and may stop the logging processes without raising an alarm. Every design decision on this page answers one of those three.
- Capture must sit outside the decoy. If the only record of attacker activity is produced on the decoy host, an attacker with administrative control can switch it off. Network capture and remote logging are part of the countermeasure.
- The ATT&CK mapping is thin. D3FEND relates D3-IHN to ATT&CK only through one inferred relation, System Information Discovery (T1082), inherited from its parent's Decoy Artifact. Value comes from what the attacker does once inside, not from a technique list.
- Choose it last, not first. Most organisations get the detection benefit with lower risk from connected or standalone honeynets and decoy objects; integrated honeynets suit mature teams that want to study an intruder's tradecraft in their own environment.
D3-IHN at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-IHN (d3f:IntegratedHoneynet) |
| Tactic | Deceive |
| Parent technique | Decoy Environment (D3-DE), synonym "Honeypot": "A Decoy Environment comprises hosts and networks for the purposes of deceiving an attacker." |
| Digital artefact | Intranet Network (D3FEND relation: spoofs Intranet Network); the parent manages Decoy Artifact |
| Interaction level | Full: real operating systems and software, not emulated services |
| D3FEND reference | Palo Alto Networks patent application US20170019425A1, "Synchronizing a honey network configuration to reflect a target network environment"; considerations cite Roger Grimes, Honeypots for Windows (2005) |
| Main benefit | High-fidelity alerts and a complete record of attacker behaviour on realistic systems |
| Main risk | The decoy becomes a launch point, a sniffing point or a blind spot |
How it works
D3FEND's parent technique sets the detection principle: systems in a decoy environment are configured so that some detectable means of communication has no legitimate business purpose, and any communication through it is logged and analysed for indicators of compromise. An integrated honeynet applies that principle with real hosts on the production network, using computing resources or software chosen to attract attackers and giving them full interaction.
The reference D3FEND attaches to the technique describes one way to keep such decoys believable. As summarised in D3FEND's reference abstract, the Palo Alto Networks application describes a device profile data store holding attributes of devices in the target network, a library of virtual machine images, and a virtual clone manager that instantiates clones of real devices customised from those attributes. The design point is synchronisation: decoys that mirror the operating systems, software and naming of the surrounding estate are harder to tell apart from production.
Integrated, connected or standalone
D3FEND defines three honeynet variants under Decoy Environment. The table compares them using D3FEND's own definitions and considerations.
| Variant | D3FEND definition (summarised) | Realism | Risk to production | D3FEND consideration |
|---|---|---|---|---|
| Integrated Honeynet (D3-IHN) | Decoys set in the production environment, full production environments connected to the enterprise network | Highest: full interaction | Highest | Attacker may attack connected hosts, eavesdrop or stop logging |
| Connected Honeynet (D3-CHN) | Decoys connected to the enterprise network that emulate certain functionality without exposing a full production system | Medium: emulated services or OS portions | Medium | May not detect new attack patterns or zero days, but can cover specific known vulnerabilities |
| Standalone Honeynet (D3-SHN) | An environment for attracting attackers that is not connected to any production enterprise systems | Lower unless extra effort is made | Lowest | Loss of fidelity and realism; significant effort to look realistic |
See D3-CHN Connected Honeynet and D3-SHN Standalone Honeynet for the other two variants.
ATT&CK techniques D3FEND relates to D3-IHN
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-IHN, and no ATT&CK technique in D3FEND acts on its own artefact, Intranet Network. The one relation shown on the D3FEND page (D3FEND 1.6.0, checked November 2026) is inferred through the Decoy Artifact that the parent technique manages. D3FEND labels such relations inferred and experimental. The ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation (inferred via artefact) | What an integrated honeynet sees |
|---|---|---|---|
| T1082 | System Information Discovery | Decoy Artifact: technique may access it | An intruder on a decoy host enumerating its operating system, configuration and software, which is often the first activity after access |
In practice, a full-interaction decoy records whatever the intruder does next: network discovery, credential access, lateral movement attempts and tool transfer. Those observations are the output of the countermeasure, but D3FEND does not formally map them, so this card does not list them as coverage.
Where it is implemented
| Implementation class | What it provides | Fits when |
|---|---|---|
| Self-built high-interaction decoy hosts | Real virtual machines built from the organisation's own images, placed in production subnets, with no business users or workloads | The team has build automation, network control and forensic skills in house |
| Deception platforms with full-OS decoys | Managed decoy hosts cloned or profiled from production, central alerting, and lures on real endpoints that point to the decoys | Larger estates that want consistency and lifecycle management; see the Deception Technology Guide |
| Cloud decoy workloads | Decoy instances, storage and identities inside production cloud accounts or networks, observed through provider flow logs, audit logs and traffic mirroring | Most attacker activity you expect is in cloud estates |
| Network capture and control layer | A gateway, tap or mirror that records all decoy traffic and restricts what leaves the decoys, outside the attacker's reach | Always: this is the part of the design that answers D3FEND's three risks |
Implementation steps
- State the purpose and get approval. Write down whether the goal is early detection, studying tradecraft or both, and who may watch an intruder rather than evict them. NIST SP 800-53 SC-26 guidance notes that decoys need supporting isolation measures and that consultation with legal counsel before deployment may be needed.
- Build decoys from production images. Use the same operating system builds, agents, naming conventions and directory membership as nearby real hosts, following the synchronisation idea in D3FEND's reference. Remove anything sensitive: no real data, no real credentials, no trust relationships that grant access to production.
- Design containment for the first risk. Restrict decoy-originated traffic at the network layer so a compromised decoy can reach other decoys and the capture layer but is blocked from, or tightly limited towards, real production hosts and the internet. Configure production hosts and their monitoring to treat any connection from a decoy address as an alert, which D3FEND's consideration on internal hosts not configured to react to honeynet connections points to directly.
- Design capture for the third risk. Record decoy traffic at a tap, mirror or gateway the decoy cannot administer, and forward host logs off-box in real time. Alert on the loss of a decoy's log stream as a security event, not an operational one.
- Limit what can be overheard for the second risk. Place decoys in segments where an attacker with packet capture on the decoy sees decoy traffic, not production authentication or management traffic. Avoid sharing broadcast domains with sensitive systems.
- Add lures that lead in. Credentials, file shares and host entries on real systems that point to the decoys; see D3-DUC Decoy User Credential and D3-DF Decoy File.
- Pilot in one segment. Run for several weeks, remove legitimate triggers such as asset scanners and backup jobs by fixing the source, and rehearse the response.
- Write the engagement and eviction rules. Define how long an intruder may be observed, what event ends observation (an attempt to reach production, data staging, destructive behaviour), and how the decoy is cut off and rebuilt.
- Roll back cleanly. To retire a decoy, remove its lures from real systems first, then remove the host, then keep the detection rules for the decoy's addresses and names for a period so late use is still caught.
Where identity fits
Decoy hosts in an integrated honeynet usually need directory membership and service accounts to look real, and that creates real identities. Give decoy machine and service accounts no rights on production resources, keep them out of privileged groups, and alert on any use of them outside the decoy segment. A decoy service account with a reused password or a delegation right on a real server turns the honeynet into an access path. The Decoy accounts in Active Directory guide covers the directory side.
How to verify it works
- Containment test: from each decoy, attempt approved connections towards production and the internet on a schedule, and confirm they are blocked and alerted on.
- Capture test: stop the logging service on a decoy during a test and confirm the network capture still records activity and the log-loss alert fires.
- Detection test: run an authorised interaction with a decoy (a logon, a share access, a discovery command) and confirm the alert reaches the queue with the source host.
- Realism review: compare decoy builds against current production images each quarter; drift in patch levels, agents or naming makes decoys easy to spot.
- Emulation exercises: include the honeynet in authorised red team work and record whether the team found, used or avoided the decoys.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Scheduled containment tests passed | 100% | Proves a compromised decoy cannot be used against production |
| Decoys with off-box capture and a working log-loss alert | 100% | Answers D3FEND's "stop logging" risk |
| Benign triggers per month after pilot | Close to zero | Keeps decoy alerts high priority |
| Decoy builds within one patch cycle of production images | All decoys | Realism decays without upkeep |
| Time from first decoy interaction to analyst acknowledgement | Tracked per exercise and incident | Shows whether the detection is acted on |
Limits, bypasses and failure patterns
- The decoy as a launch point: permissive routing from decoys to production turns the honeynet into a foothold, the first risk D3FEND lists. Containment is part of the countermeasure, not an optional extra.
- Blind spots from host-only logging: an intruder with administrative rights stops the agent and the decoy goes quiet. Without off-box capture, silence looks like no activity.
- Eavesdropping on shared segments: a decoy on the same segment as real servers can capture their traffic, including authentication material.
- Stale decoys: decoys that miss months of patches or carry old agent versions stand out, and unpatched full-OS decoys are genuinely exploitable.
- Real data or credentials left behind: a decoy cloned from production with a real configuration file or cached credentials leaks the very thing it was meant to protect.
- Running the platform as an unprotected system: the deception management plane knows where every decoy is. See Securing the deception platform itself.
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; guidance requires supporting isolation measures |
| NIST SP 800-53 Rev 5 | SC-30 Concealment and Misdirection | Misdirecting adversaries |
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection, SI-4(4) Inbound and Outbound Communications Traffic | Containing decoy traffic and monitoring it |
| NIST SP 800-53 Rev 5 | AU-9 Protection of Audit Information | Keeping decoy records out of the attacker's reach |
| NIST CSF 2.0 | DE.CM-01, DE.AE-02 | Monitoring networks and analysing adverse events |
| MITRE D3FEND | D3-DE, D3-IHN | Parent and technique |
Practitioner checklist
- Record the purpose, approver and legal review for the honeynet.
- Build decoys from current production images with no real data or credentials.
- Block or tightly limit decoy-originated traffic towards production and the internet.
- Alert on any connection from a decoy address to a production host.
- Capture decoy traffic and logs off-box and alert on log loss.
- Keep decoys off segments that carry sensitive production traffic.
- Give decoy machine and service accounts no production rights.
- Test containment, capture and detection on a schedule and record results.
- Define when observation ends and how a decoy is cut off and rebuilt.
Standards and references
- MITRE D3FEND: Integrated Honeynet (D3-IHN)
- MITRE D3FEND: Decoy Environment (D3-DE)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-26 Decoys)
- ENISA: Proactive Detection of Security Incidents II, Honeypots
- MITRE ATT&CK: T1082 System Information Discovery
- MITRE D3FEND: Connected Honeynet (D3-CHN)
Related NHI Mgmt Group resources: Honeypot deployment · Deception Technology Deployment Guide · Deception Technology Guide · Securing the deception platform itself · MITRE D3FEND Guide