Deception Levels

The Cyber Deception Playground supports four progressive deception levels, each adding more techniques to increase an attacker’s decision-making cost. Levels are selected at startup and control which Docker Compose profiles activate and which database schema is loaded.

Capability Overview

Capability

none

basic

complete

impossible

Production services (frontend, backend, MySQL)

✅

✅

✅

✅

Elastic Stack monitoring (Filebeat, Elasticsearch, Kibana)

✅

✅

✅

✅

Attacker container

✅

✅

✅

✅

SSH Honeypot

❌

✅

✅

✅

Fake credentials in userdb

❌

✅

✅

✅

Decoy config files (/config directory)

❌

✅

✅

✅

Fake Activity Generator

❌

❌

✅

✅

Decoy API endpoints / honeytokens

❌

❌

✅

✅

Hidden HTML links injected into pages

❌

❌

✅

✅

Extra decoy DB columns (password2, password_selector)

❌

❌

✅

✅

Exposed system_config table with API keys / SSH keys

❌

❌

❌

✅

Fake file_system and network_info tables

❌

❌

❌

✅

exposed_credentials SQL view (honeypot)

❌

❌

❌

✅

20+ decoy user accounts in database

❌

❌

❌

✅

Modified service banners (T1592 misdirection)

❌

❌

❌

✅

Anti-forensics indicators (T1070 detection)

❌

❌

❌

✅

Tampered executables / decoy binaries (T1036.005 misdirection)

❌

❌

❌

✅

Level: none

The production baseline. No deception is active — the environment is vulnerable but not defended.

What an attacker sees:

  • A standard financial web portal (Andesfinance) on port 3000.

  • SQL injection and command injection vulnerabilities in the application.

  • No SSH honeypot, no fake data, no decoy endpoints.

  • Kibana and Elasticsearch available for monitoring (defender only).

Purpose: Establish the undeceived baseline. Useful for demonstrating what a successful attack looks like without defensive measures, and for measuring the attacker’s time-to-exfiltration.

Start command:

./scripts/startup.sh none

Level: basic

Adds the first deception layer: an SSH honeypot and fake credentials to detect and misdirect initial access attempts.

What changes:

  • SSH Honeypot (ssh-honeypot/) starts listening on port 22. It accepts connections but logs every authentication attempt, command, and session to ssh_connections.json (shipped to Elasticsearch via Filebeat).

  • Fake user database (ssh-honeypot/config/userdb.txt) contains low-entropy credentials (root/toor, admin/admin123, backup/backup123) that an attacker will discover during brute force and attempt to reuse.

  • Decoy config files become accessible at /config. The directory listing exposes files like aws-credentials.json, database.conf, and environment.env — all containing fictitious but realistic-looking secrets.

What an attacker sees:

  • An SSH service that accepts their credentials and appears functional.

  • Config files with credentials that look valid and tempt lateral movement.

  • More activity in Elasticsearch as the honeypot logs every connection attempt.

Purpose: Demonstrate the simplest deception — a single layer of misdirection that immediately surfaces attacker behavior in logs.

Start command:

./scripts/startup.sh basic

Level: complete

Adds active deception that generates noise, expands the attack surface, and makes it harder to distinguish real assets from decoys.

What changes beyond basic:

  • Fake Activity Generator (fake-activity/) starts running. It creates realistic SSH sessions using paramiko, executing role-appropriate commands (e.g., root runs ps aux, cat /etc/passwd; juan runs ls -la, df -h) every 10–30 seconds. These sessions are indexed in Elasticsearch with fake_activity: true — they look identical to real attacker sessions in logs.

  • Decoy API endpoints activate in the backend. Endpoints like /admin/backup, /internal/config, /internal/secrets, and /dev/database respond with convincing fake data and log every access as a security indicator.

  • Hidden HTML links are injected into the frontend’s homepage pointing to the decoy endpoints. They are invisible in the browser but visible to web crawlers and automated scanners.

  • Extra database columns: users table gains password2 (alternate password) and password_selector (single-character flag). An attacker who extracts the schema and finds these will spend time trying to use them, generating additional detectable activity.

What an attacker sees:

  • SSH activity that looks like other users are active on the system.

  • Juicy-looking admin endpoints that log every access.

  • Database columns suggesting a more complex authentication scheme.

  • More apparent targets, increasing the time spent before reaching real assets.

Purpose: Force the attacker to slow down and validate each finding. Every interaction with a decoy generates a high-confidence alert.

Start command:

./scripts/startup.sh complete

Level: impossible

Maximum deception. The attacker is surrounded by convincing but false information at every layer of the stack.

What changes beyond complete:

Database layer

The init-impossible.sql script loads the most extensive deceptive dataset:

  • ``system_config`` table — 22 rows of fake but realistic-looking secrets: Stripe live keys, PayPal client secrets, AWS access/secret keys, JWT secrets, SMTP passwords, Redis/Elasticsearch/Kibana/Grafana/Jenkins/Git tokens, a backup encryption key, and a disaster recovery token. Every exfiltration of this table gives an attacker a long list of credentials to test and pivot on — all false.

  • ``api_keys`` table — 8 rows with realistic API keys for Stripe, PayPal, AWS S3, JWT, email, Redis, Elasticsearch, and Kibana.

  • ``ssh_keys`` table — 5 rows with fake RSA, Ed25519, and ECDSA private keys for production, development, staging, backup, and AWS servers.

  • ``file_system`` table — mimics /proc-style data: fake entries for /etc/passwd, /etc/shadow, /home/admin/.ssh/id_rsa, and /var/log/auth.log with realistic content previews.

  • ``network_info`` table — maps internal hostnames to IPs and ports, giving an attacker a ready-made internal network map that may not match reality.

  • ``exposed_credentials`` view — a SQL view that joins 20 decoy users with their plaintext passwords, specifically named to attract an attacker scanning for low-hanging fruit.

  • 20+ decoy user accounts — service accounts (jenkins, git_user, elastic, kibana, logstash, grafana, aws_user, dr_admin, etc.) each with two password variants (password and password2) and a password_selector flag. Brute force or SQLi extraction surfaces dozens of credentials to test.

Service banners

Modified service response headers and SSH banners present misleading version information (e.g., an older, patchable version) to misdirect fingerprinting and exploit selection.

Anti-forensics indicators

The environment logs specific patterns that would only appear if an attacker attempts log deletion or evidence tampering (T1070). These are detected by Filebeat and generate CRITICAL severity alerts.

Tampered executables / decoy binaries

Selected system tools inside containers are replaced or wrapped with decoy versions that log their invocation. When an attacker runs a tool expecting silent output, the execution is recorded as a high-fidelity indicator (T1036.005).

What an attacker sees:

  • Every database table contains a mix of real vulnerabilities and false data.

  • Credential extraction yields dozens of API keys, SSH keys, and passwords — all invalid.

  • Network maps point to hosts that may not exist or are additional honeypots.

  • Even forensic cleanup attempts trigger alerts.

Purpose: Maximize attacker confusion and dwell-time. Every action generates signal. By the time the attacker realizes the environment is deceptive, they have fully revealed their tooling, techniques, and objectives in the logs.

Start command:

./scripts/startup.sh impossible

Attacker Experience by Level

The table below describes what a skilled attacker observes at each level after running the full 7-phase attack simulation.

Observation

none

basic

complete

impossible

SQL injection extracts real users only

✅

✅

Mix of real + decoy columns

Real + decoy + fake service accounts

SSH brute force hits real service

No SSH

Honeypot only

Honeypot + fake activity noise

Honeypot + fake activity noise

Config files reveal credentials

❌

✅ (fictitious)

✅ (fictitious)

✅ (fictitious + API key table)

Decoy API endpoints respond

❌

❌

✅ (logs access)

✅ (logs access)

Database holds API / SSH keys

❌

❌

❌

✅ (all false)

Log deletion detected

❌

❌

❌

✅

Choosing a Level for Demos

  • Arsenal / conference demo: Use complete — it generates the most visual activity in Kibana without overwhelming first-time audiences.

  • Workshop / hands-on training: Use basic first, then switch to complete to show the impact of each added layer.

  • Advanced red team research: Use impossible — it tests whether tooling and techniques survive maximum deception density.

  • Baseline measurement: Use none — no noise, pure vulnerability exposure.