Description
Provision isolated network segments that mirror the organization's production topology. These shadow networks host deception assets while maintaining sufficient isolation to prevent adversary pivot back to production and sufficient connectivity to appear legitimate.
Rationale
A convincing deception environment starts with a convincing network. Adversaries who gain access to a network segment immediately assess its topology, naming conventions, and connectivity patterns. Shadow networks that mirror production make the deception environment feel like a natural extension of the real infrastructure.
Supporting Basis
Direct antecedentMITRE Engage describes an isolated engagement network, while Trassare et al. implement a synthetic deceptive topology.
- The MITRE Corporation. A Practical Guide to Adversary Engagement, version 1.0. 2022.Technical guide
- Trassare, S.T.; Beverly, R.; Alderson, D. A Technique for Network Topology Deception. MILCOM 2013, 1795–1800.Peer reviewed
These sources establish design lineage and scope. They do not validate this record's operational effectiveness, planning estimates, environment labels, or ATT&CK relationships.
Implementation Steps
Design shadow network topology
Create a network design that mirrors production naming conventions, subnet structures, and VLAN configurations. Include realistic gateway addresses and DNS configurations.
Provision network infrastructure
Deploy virtual switches, routers, and firewalls to create the shadow network segments. In cloud environments, this translates to VPCs, subnets, and security groups.
Configure routing and isolation
Set up routing that allows controlled traffic flow into the deception environment while preventing adversary lateral movement back to production. Implement strict egress filtering.
Deploy network services
Activate network services (DHCP, DNS, NTP) within the shadow network that adversaries would expect to find in a real environment.
Validate network realism
Perform network scans and enumeration from the perspective of an adversary to verify that the shadow network presents a believable profile.
Technical Implementation Examples(2)
Deception VPC with Isolation Controls (AWS)
Terraform module to provision an isolated deception VPC with controlled peering to production
# modules/shadow-network/main.tf
variable "environment_id" { type = string }
variable "production_vpc_cidr" { type = string }
variable "deception_cidr" { type = string, default = "10.200.0.0/16" }
resource "aws_vpc" "shadow" {
cidr_block = var.deception_cidr
enable_dns_support = true
enable_dns_hostnames = true
tags = { Name = "internal-svcs-${var.environment_id}" }
}
# Mimic production subnet naming conventions
resource "aws_subnet" "decoy_subnets" {
for_each = {
web = { cidr = "10.200.10.0/24", az = "us-east-1a" }
app = { cidr = "10.200.20.0/24", az = "us-east-1a" }
db = { cidr = "10.200.30.0/24", az = "us-east-1b" }
admin = { cidr = "10.200.40.0/24", az = "us-east-1b" }
}
vpc_id = aws_vpc.shadow.id
cidr_block = each.value.cidr
availability_zone = each.value.az
tags = { Name = "prod-${each.key}-${var.environment_id}" }
}
# Isolation: decoys can receive traffic but cannot reach production
resource "aws_network_acl" "isolation" {
vpc_id = aws_vpc.shadow.id
subnet_ids = [for s in aws_subnet.decoy_subnets : s.id]
# Allow inbound from production
ingress {
protocol = "tcp"
rule_no = 100
action = "allow"
cidr_block = var.production_vpc_cidr
from_port = 0
to_port = 65535
}
# DENY outbound to production (critical isolation control)
egress {
protocol = "tcp"
rule_no = 50
action = "deny"
cidr_block = var.production_vpc_cidr
from_port = 0
to_port = 65535
}
# Allow outbound to management/logging subnet
egress {
protocol = "tcp"
rule_no = 100
action = "allow"
cidr_block = "10.200.99.0/24"
from_port = 0
to_port = 65535
}
tags = { Name = "shadow-isolation-nacl" }
}
# VPC Flow Logs: capture all traffic for analysis
resource "aws_flow_log" "shadow_flows" {
vpc_id = aws_vpc.shadow.id
traffic_type = "ALL"
log_destination_type = "cloud-watch-logs"
log_destination = aws_cloudwatch_log_group.shadow.arn
iam_role_arn = aws_iam_role.flow_log.arn
}
resource "aws_cloudwatch_log_group" "shadow" {
name = "/shadow-cdf/vpc-flow-logs"
retention_in_days = 90
}Shadow Network - Azure Virtual Network
Terraform configuration for deploying an isolated deception virtual network in Azure
# modules/shadow-network-azure/main.tf
resource "azurerm_virtual_network" "shadow" {
name = "vnet-internal-services-02"
location = var.location
resource_group_name = var.resource_group_name
address_space = ["10.200.0.0/16"]
tags = { environment = "deception", managed_by = "shadow-cdf" }
}
resource "azurerm_subnet" "decoy_web" {
name = "snet-web-prod-02"
resource_group_name = var.resource_group_name
virtual_network_name = azurerm_virtual_network.shadow.name
address_prefixes = ["10.200.10.0/24"]
}
resource "azurerm_subnet" "decoy_db" {
name = "snet-db-prod-02"
resource_group_name = var.resource_group_name
virtual_network_name = azurerm_virtual_network.shadow.name
address_prefixes = ["10.200.20.0/24"]
}
# NSG: allow inbound from production, block outbound to production
resource "azurerm_network_security_group" "isolation" {
name = "nsg-shadow-isolation"
location = var.location
resource_group_name = var.resource_group_name
security_rule {
name = "AllowProductionInbound"
priority = 100
direction = "Inbound"
access = "Allow"
protocol = "Tcp"
source_address_prefix = var.production_vnet_cidr
destination_address_prefix = "*"
source_port_range = "*"
destination_port_range = "*"
}
security_rule {
name = "DenyProductionOutbound"
priority = 100
direction = "Outbound"
access = "Deny"
protocol = "*"
source_address_prefix = "*"
destination_address_prefix = var.production_vnet_cidr
source_port_range = "*"
destination_port_range = "*"
}
}
# Network Watcher flow logs for traffic capture
resource "azurerm_network_watcher_flow_log" "shadow" {
name = "flowlog-shadow-vpc"
network_watcher_name = var.network_watcher_name
resource_group_name = var.resource_group_name
network_security_group_id = azurerm_network_security_group.isolation.id
storage_account_id = var.log_storage_account_id
enabled = true
retention_policy {
enabled = true
days = 90
}
}MITRE ATT&CK Mappings
| Technique | Tactic | Relationship |
|---|---|---|
| T1046Network Service Discovery | Discovery | counters |
| T1021Remote Services | Lateral Movement | detects |
Environment-Specific Guidance
Deploy using dedicated VLANs and virtual switches. Physical isolation through separate switch ports provides the strongest guarantee.
Use dedicated VPCs with restricted VPC peering or Transit Gateway connections. Leverage Security Groups and NACLs for isolation.
Deploy to dedicated Virtual Networks with NSG rules. Use Azure Firewall for controlled connectivity to production VNets.
Create dedicated VPC networks with firewall rules. Use VPC Network Peering with restricted route exchange for controlled connectivity.
Implement shadow network segments in both on-premise and cloud environments. Ensure the hybrid connectivity (VPN/Direct Connect) configuration mirrors production.
Considerations
- Isolation is paramount. A misconfigured route that allows adversary pivot from deception to production defeats the entire purpose.
- Network fingerprinting tools can detect inconsistencies in virtual network implementations. Test with the same tools adversaries use.
- Shadow networks in cloud environments may incur ongoing costs even when idle. Plan for this in the budget.
Supported Environments
Tools & Resources
- Terraform for infrastructure provisioning
- Ansible for network configuration
- Virtual networking platforms (VMware NSX, Open vSwitch)
- Cloud networking (AWS VPC, Azure VNet, GCP VPC)
Related Techniques
Quick Stats
- Phase
- Prepare
- Difficulty
- advanced
- Detection Value
- high
- Cost
- moderate
- Time
- 1-3 weeks
- ATT&CK Mappings
- 2