Description
Deploy interactive honeypots at strategic network locations where adversaries may encounter them during lateral movement, privilege escalation, or data discovery. Monitor interactions as high-suspicion events and document authorized test activity and other expected contact.
Rationale
Honeypots can provide comparatively focused observations because legitimate workflows should not normally depend on them. An interaction is therefore a high-suspicion signal, not conclusive evidence of malicious intent. Placement along plausible attack paths can increase the opportunity for relevant engagement but requires local validation.
Supporting Basis
Direct antecedentThe sources treat network placement and interspersion with real assets as material deployment choices.
- Spitzner, L. Honeypots: Tracking Hackers. Addison-Wesley Professional, 2003.Practitioner book
- Ferguson-Walter, K.J. et al. Examining the Efficacy of Decoy-Based and Psychological Cyber Deception. USENIX Security 2021, 1127–1144.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
Identify placement locations
Based on the architecture blueprint, identify network segments and subnets where honeypots will provide the best coverage along likely adversary paths.
Select honeypot type
Choose between low-interaction (port listeners, banner emulators) and high-interaction (full OS, real services) honeypots based on intelligence objectives and resource availability.
Deploy and configure
Install honeypot systems at designated locations. Configure services, network profiles, and system artifacts to match the expected profile for each location.
Validate monitoring coverage
Confirm that all honeypot interactions are being captured and forwarded to the monitoring pipeline. Test by generating synthetic interactions.
Document and communicate
Document honeypot locations, configurations, and expected alert profiles. Communicate to SOC and IR teams so they can appropriately triage deception alerts.
Technical Implementation Examples(2)
T-Pot Honeypot Platform Deployment
Automated deployment of T-Pot multi-honeypot platform on a dedicated deception host
#!/bin/bash
# deploy-tpot.sh
# Deploy T-Pot multi-honeypot platform on a dedicated VM
# T-Pot includes: Cowrie, Dionaea, Honeytrap, Conpot, and more
# Requires: Ubuntu 22.04+, 8GB RAM, 128GB disk minimum
set -euo pipefail
TPOT_VERSION="24.04"
TPOT_TYPE="STANDARD" # STANDARD, HIVE, or SENSOR
echo "[*] Preparing system for T-Pot deployment..."
# Update and install prerequisites
apt-get update -qq
apt-get install -y -qq git curl
# Clone T-Pot installer
git clone https://github.com/telekom-security/tpotce /opt/tpot
cd /opt/tpot
echo "[*] Running T-Pot installer..."
echo "[*] Type: $TPOT_TYPE"
# Non-interactive install
export TPOT_OSTYPE="auto"
./install.sh --type="$TPOT_TYPE" --conf=/opt/tpot/iso/installer/tpot.conf
echo "[+] T-Pot installation complete."
echo "[*] Access the web interface at https://<host-ip>:64297"
echo "[*] SSH management port relocated to 64295"
echo ""
echo "[!] IMPORTANT: Configure your SIEM to ingest from:"
echo " - Logstash output: port 64305"
echo " - EWS (Early Warning System): port 64306"
echo ""
echo "[!] Ensure this host is placed on a deception subnet"
echo " per the ShadowMatrix CDF architecture blueprint."Targeted Honeypot Placement with Terraform
Deploy honeypots on specific subnets along identified lateral movement paths
# modules/honeypot-placement/main.tf
# Deploy honeypots at strategic points along lateral movement paths
variable "placement_configs" {
description = "Honeypot placement specifications"
type = list(object({
subnet_id = string
role_name = string # What the honeypot pretends to be
services = list(string)
hostname = string
}))
default = [
{
subnet_id = "subnet-web-tier"
role_name = "web-server"
services = ["ssh", "http", "https"]
hostname = "prod-web-08"
},
{
subnet_id = "subnet-db-tier"
role_name = "database"
services = ["ssh", "postgresql", "mysql"]
hostname = "prod-db-04"
},
{
subnet_id = "subnet-admin"
role_name = "jump-host"
services = ["ssh", "rdp"]
hostname = "admin-jump-03"
},
]
}
resource "aws_instance" "honeypot" {
for_each = { for idx, cfg in var.placement_configs :
cfg.role_name => cfg
}
ami = data.aws_ami.ubuntu.id
instance_type = "t3.small"
subnet_id = each.value.subnet_id
vpc_security_group_ids = [aws_security_group.honeypot[each.key].id]
tags = {
Name = each.value.hostname
Role = each.value.role_name
# Internal tracking - not visible via instance metadata
}
user_data = templatefile("${path.module}/scripts/honeypot-init.sh", {
hostname = each.value.hostname
services = join(",", each.value.services)
siem_host = var.siem_endpoint
})
}
# Dynamic security groups based on the services each honeypot emulates
resource "aws_security_group" "honeypot" {
for_each = { for idx, cfg in var.placement_configs :
cfg.role_name => cfg
}
name = "sg-honeypot-${each.key}"
vpc_id = var.deception_vpc_id
dynamic "ingress" {
for_each = toset(each.value.services)
content {
from_port = lookup(local.service_ports, ingress.value, 0)
to_port = lookup(local.service_ports, ingress.value, 0)
protocol = "tcp"
cidr_blocks = [var.production_cidr]
description = "Allow ${ingress.value} from production"
}
}
}
locals {
service_ports = {
ssh = 22
http = 80
https = 443
rdp = 3389
postgresql = 5432
mysql = 3306
smb = 445
ftp = 21
}
}MITRE ATT&CK Mappings
| Technique | Tactic | Relationship |
|---|---|---|
| T1021Remote Services | Lateral Movement | detects |
| T1570Lateral Tool Transfer | Lateral Movement | detects |
| T1210Exploitation of Remote Services | Lateral Movement | detects |
Considerations
- Honeypot density should match the network density of real assets. A single honeypot in a subnet with dozens of real servers is appropriately subtle. A single honeypot on an otherwise empty subnet is suspicious.
- Consider deploying honeypots that match the role suggested by their network location. A honeypot in a database subnet should present database services.
- High-interaction honeypots require more maintenance but yield richer intelligence about adversary behavior after initial access.
Supported Environments
Tools & Resources
- T-Pot (multi-honeypot platform)
- Cowrie (SSH/Telnet)
- Dionaea (multi-protocol)
- HoneySMB, HoneyDB
- Custom honeypot applications
Related Techniques
Quick Stats
- Phase
- Deploy
- Difficulty
- intermediate
- Detection Value
- critical
- Cost
- low
- Time
- 3-7 days
- ATT&CK Mappings
- 3