Matrix/Deploy/SDF-DP01

SDF-DP01

Honeypot Placement

intermediateDetection Value: criticalCost: lowTime: 3-7 days🖥 Endpoint Systems

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 antecedent

The sources treat network placement and interspersion with real assets as material deployment choices.

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

1

Identify placement locations

Based on the architecture blueprint, identify network segments and subnets where honeypots will provide the best coverage along likely adversary paths.

2

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.

3

Deploy and configure

Install honeypot systems at designated locations. Configure services, network profiles, and system artifacts to match the expected profile for each location.

4

Validate monitoring coverage

Confirm that all honeypot interactions are being captured and forwarded to the monitoring pipeline. Test by generating synthetic interactions.

5

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

bash
#!/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

cloud-awshcl
# 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

TechniqueTacticRelationship
T1021Remote ServicesLateral Movementdetects
T1570Lateral Tool TransferLateral Movementdetects
T1210Exploitation of Remote ServicesLateral Movementdetects

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

🏢On-Premise
☁Amazon Web Services
☁Microsoft Azure
☁Google Cloud Platform
🔄Hybrid Environment
🏭OT/ICS Environment

Tools & Resources

  • T-Pot (multi-honeypot platform)
  • Cowrie (SSH/Telnet)
  • Dionaea (multi-protocol)
  • HoneySMB, HoneyDB
  • Custom honeypot applications

Quick Stats

Phase
Deploy
Difficulty
intermediate
Detection Value
critical
Cost
low
Time
3-7 days
ATT&CK Mappings
3