Description
Create decoy hosts with realistic operating system configurations, installed software, user artifacts, and operational history. These hosts must withstand scrutiny from adversaries who will inspect system details to determine if they have landed on a real target.
Rationale
Adversaries may assess installed software, user login history, file timestamps, process lists, and network connections when deciding whether a system is worth further attention. Providing internally consistent artifacts can make a decoy less conspicuous, although realism and engagement outcomes must be evaluated in the target environment.
Supporting Basis
Direct antecedentThe sources describe building decoy hosts and personas and constructing realistic server decoys using replayed activity.
- The MITRE Corporation. A Practical Guide to Adversary Engagement, version 1.0. 2022.Technical guide
- Sun, J.; Sun, K.; Li, Q. Towards a Believable Decoy System: Replaying Network Activities from Real System. IEEE CNS 2020, 1–9.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
Select base operating systems
Choose operating systems and versions that match your production environment. If production runs Windows Server 2019 and Ubuntu 22.04, decoy hosts should run the same.
Install production-matching software
Install the same applications, tools, and agents that exist on production systems. Include monitoring agents, backup clients, and business applications.
Generate realistic system history
Create login history, browser history, command history, and scheduled tasks that make the system appear actively used. Automate periodic activity to maintain freshness.
Configure realistic network profile
Ensure the host responds to network queries (DNS, NetBIOS, mDNS) consistently with its role. Set appropriate hostnames and domain membership.
Instrument for monitoring
Install monitoring agents that capture all adversary interactions while remaining invisible to casual inspection. Use kernel-level logging where possible.
Technical Implementation Examples(2)
Decoy Host Provisioning with Ansible
Ansible playbook that configures a Linux VM to appear as an active production server with realistic artifacts
# playbooks/configure-decoy-host.yml
---
- name: Configure Decoy Host with Realistic Artifacts
hosts: decoy_hosts
become: true
vars:
decoy_hostname: "prod-app-srv-07"
decoy_domain: "corp.internal"
fake_users:
- { name: "j.martinez", uid: 1201, comment: "Juan Martinez - DevOps" }
- { name: "s.thompson", uid: 1202, comment: "Sarah Thompson - DBA" }
- { name: "m.chen", uid: 1203, comment: "Michael Chen - SRE" }
tasks:
- name: Set realistic hostname
ansible.builtin.hostname:
name: "{{ decoy_hostname }}"
- name: Install production-matching packages
ansible.builtin.apt:
name:
- apache2
- postgresql-client
- python3
- openssh-server
- net-tools
- curl
- git
- docker.io
state: present
update_cache: true
- name: Create decoy user accounts
ansible.builtin.user:
name: "{{ item.name }}"
uid: "{{ item.uid }}"
comment: "{{ item.comment }}"
shell: /bin/bash
create_home: true
password: "{{ 'DecoyPassword!' | password_hash('sha512') }}"
loop: "{{ fake_users }}"
- name: Generate realistic bash history for each user
ansible.builtin.copy:
dest: "/home/{{ item.name }}/.bash_history"
owner: "{{ item.name }}"
mode: "0600"
content: |
ssh prod-db-01.corp.internal
sudo systemctl status postgresql
tail -f /var/log/application/app.log
kubectl get pods -n production
docker ps
git pull origin main
cd /opt/application && ./deploy.sh
psql -h prod-db-01 -U appuser -d customerdb
cat /etc/hosts
ping monitoring.corp.internal
loop: "{{ fake_users }}"
- name: Create realistic directory structure
ansible.builtin.file:
path: "{{ item }}"
state: directory
mode: "0755"
loop:
- /opt/application
- /opt/application/config
- /opt/application/logs
- /var/backups/daily
- /etc/monitoring
- name: Plant decoy application config with trap credentials
ansible.builtin.copy:
dest: /opt/application/config/database.yml
mode: "0640"
content: |
# Database configuration - PRODUCTION
# Last updated: 2026-02-15 by j.martinez
production:
adapter: postgresql
host: prod-db-01.corp.internal
port: 5432
database: customerdb
username: app_svc_prod
password: "Pr0d-Db#2026!xK9m"
pool: 25
timeout: 5000
- name: Create cron jobs that make the host look active
ansible.builtin.cron:
name: "{{ item.name }}"
minute: "{{ item.minute }}"
hour: "{{ item.hour }}"
job: "{{ item.job }}"
loop:
- { name: "log rotation", minute: "0", hour: "2",
job: "/usr/sbin/logrotate /etc/logrotate.conf" }
- { name: "health check", minute: "*/5", hour: "*",
job: "curl -s http://localhost/health > /dev/null 2>&1" }
- { name: "backup sync", minute: "30", hour: "1",
job: "/opt/application/scripts/backup.sh >> /var/log/backup.log 2>&1" }
- name: Install and configure monitoring agent (for our visibility)
ansible.builtin.copy:
dest: /etc/monitoring/auditd-deception.rules
mode: "0640"
content: |
# Audit rules for deception monitoring
# Log all command execution
-a always,exit -F arch=b64 -S execve -k deception_cmd
# Log all file access in config directories
-w /opt/application/config/ -p rwa -k deception_config_access
# Log all authentication attempts
-w /var/log/auth.log -p wa -k deception_auth
# Log network connections
-a always,exit -F arch=b64 -S connect -k deception_networkDecoy EC2 Instance (Terraform)
Terraform resource for provisioning a decoy EC2 instance with production-matching configuration
# modules/decoy-host/main.tf
variable "subnet_id" { type = string }
variable "security_group_id" { type = string }
variable "instance_profile" { type = string }
variable "decoy_role" {
type = string
default = "app-server" # app-server, db-server, web-server, file-server
}
data "aws_ami" "ubuntu" {
most_recent = true
owners = ["099720109477"] # Canonical
filter {
name = "name"
values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"]
}
}
resource "aws_instance" "decoy" {
ami = data.aws_ami.ubuntu.id
instance_type = "t3.small"
subnet_id = var.subnet_id
vpc_security_group_ids = [var.security_group_id]
iam_instance_profile = var.instance_profile
# Production-matching metadata
tags = {
Name = "prod-${var.decoy_role}-07"
Environment = "production"
Team = "platform-engineering"
CostCenter = "CC-4420"
# Internal tag for SOC - not visible to adversary
ShadowCDF = "true"
}
# Enable detailed monitoring for deception telemetry
monitoring = true
user_data = <<-EOF
#!/bin/bash
hostnamectl set-hostname prod-${var.decoy_role}-07
# Install production-matching packages
apt-get update -qq
apt-get install -y -qq apache2 postgresql-client python3 auditd
# Enable comprehensive audit logging
systemctl enable auditd
systemctl start auditd
EOF
root_block_device {
volume_size = 50
volume_type = "gp3"
encrypted = true
}
lifecycle {
# Prevent accidental destruction
prevent_destroy = false
}
}
# CloudWatch alarm: alert on ANY console login
resource "aws_cloudwatch_metric_alarm" "decoy_login" {
alarm_name = "shadow-cdf-decoy-login-${var.decoy_role}"
comparison_operator = "GreaterThanThreshold"
evaluation_periods = 1
metric_name = "StatusCheckFailed"
namespace = "AWS/EC2"
period = 60
statistic = "Maximum"
threshold = 0
alarm_actions = [var.sns_alert_topic_arn]
dimensions = { InstanceId = aws_instance.decoy.id }
}MITRE ATT&CK Mappings
| Technique | Tactic | Relationship |
|---|---|---|
| T1082System Information Discovery | Discovery | counters |
| T1057Process Discovery | Discovery | counters |
| T1083File and Directory Discovery | Discovery | counters |
Considerations
- Decoy hosts must be updated and patched on a schedule that mirrors production, or adversaries will notice the divergence.
- Running real operating systems for decoys provides the highest realism but also the highest maintenance overhead. Evaluate the trade-off against your resources.
- Consider the performance profile. A "database server" decoy with no CPU or memory utilization will look suspicious to an adversary checking resource monitors.
Supported Environments
Tools & Resources
- Virtual machine platforms (VMware, Hyper-V, KVM)
- Container platforms (Docker) for lightweight decoys
- Configuration management (Ansible, Puppet, Chef)
- Activity simulation scripts
Related Techniques
Quick Stats
- Phase
- Prepare
- Difficulty
- advanced
- Detection Value
- high
- Cost
- moderate
- Time
- 2-4 weeks
- ATT&CK Mappings
- 3