Project Mimic: Dynamic Honeypots With Live Mimicry System

The global cyber-threat landscape has evolved from opportunistic script-kiddie attacks into coordinated, per-sistent campaigns targeting critical infrastructure, financial systems, and personal devices alike [1]. Firewalls and signature-based intrusion-detection systems (IDS) constitute the traditional first line of defence; however, they share a fundamental limitation: they are reactive. A firewall blocks known malicious traffic; an IDS alerts on known attack patterns. When a threat actor deploys a previously unseen zero-day exploit, both systems may remain entirely silent [2]. Honeypots offer a complementary, proactive paradigm. By deploying decoy systems that appear to be legitimate targets, defenders can redirect attacker effort, study adversary tactics, techniques, and procedures (TTPs), and capture novel malware in a controlled environment [3]. Despite decades of research, practical honeypot deployment remains dominated by a handful of heavyweight platforms. T-Pot [4], the in-dustry reference, aggregates more than twenty containerised honeypots and requires a minimum of 8 GB of RAM, making it unsuitable for resource-constrained environments. Further-more, because T-Pot uses publicly known container images (e.g., Cowrie for SSH, Dionaea for SMB), experienced threat actors can fingerprint and evade the platform within seconds of contact.

This paper introduces Project Mimic, which addresses both limitations through two design principles:

1. Custom code, no known signatures. Every engine is written from first principles in Python, so no public fingerprint database contains its behavioural profile.
2. Asynchronous concurrency. All engines use Python’s asyncio event loop, enabling thousands of simul-taneous connections on a single thread with minimal memory overhead.

The remainder of the paper is structured as follows. Sec-tion II reviews related work. Section III presents the system architecture. Section IV details each engine implementation. Section V describes the threat-intelligence dashboard. Sec-tion VI reports experimental evaluation. Section VII dis-cusses limitations and future work. Section VIII concludes.

2. Related Work

1. Traditional Honeypot Platforms

Honeyd [6] introduced the concept of a single daemon simulating multiple virtual hosts. Cowrie [5] became the standard SSH/Telnet honeypot, faithfully emulating an inter-active Debian shell. While Cowrie is highly effective against automated bots, its banner—SSH-2.0-OpenSSH_6.0p1 Debian—is trivially identified by adversary reconnaissance tools.

2. Aggregated Platforms

T-Pot [4] bundles Cowrie, Dionaea, Conpot, Snare/Tanner, and more than fifteen additional honeypots into a single ISO. Although it provides unparalleled breadth, its fixed container signatures, high resource demands, and limited customisability have been critiqued extensively [7].

3. Dynamic and Adaptive Honeypots

Recent research has explored honeypots that adapt their configuration to match the surrounding network [2]. Mifsud et al. [8] proposed machine-learning-guided honeypot place-ment but required substantial sensor infrastructure. Project Mimic achieves comparable adaptability through a polymor-phic routing layer embedded directly in the web engine, without requiring an external ML pipeline.

TABLE 1. Project Mimic Engine Summary

4. Deception-as-a-Service

Cloud-hosted deception platforms have gained commercial traction (e.g., Attivo Networks, Illusive Networks). However, open-source, student-deployable equivalents remain scarce. Project Mimic is designed to bridge this gap.

3. System Architecture

Project Mimic is organised as a six-service Docker Compose stack, as illustrated conceptually in Table 1. Each service runs in an isolated container, communicates over a private bridge network (honeynet), and mounts a shared /logs volume for telemetry aggregation.

1. Orchestration

A single docker-compose.yml manifest starts all en-gines with one command. Each service declares restart: always, providing self-healing behaviour: should an at-tacker crash an engine, Docker restarts the container auto-matically within seconds.

2. Logging Pipeline

All engines emit structured NDJSON events to files on the shared volume. The event schema is:

{"timestamp": "...", "sensor": "WEB", "data": {"event": "credentials_captured",

"src_ip": "...", ...}}

Structuring logs as NDJSON makes them directly ingestible by industry-standard SIEM tools such as Elasticsearch or Splunk without any transformation.

4. Engine Implementations

1. Engine 1 – Asynchronous SSH Trap

The SSH engine opens TCP port 2222 using asyncio.start_server and immediately transmits the banner:

SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5

This banner mimics a fully patched Ubuntu 20.04 server, deterring trivial scanners while still attracting targeted brute-force tools. The engine captures the raw client handshake packet (which often encodes the attacker’s SSH client ver-sion and preferred cipher list), logs it as hex, and then transmits a Protocol mismatch. error.

To support post-exploitation analysis, a fake interactive shell extension was added. If the attacker presents a matching credential pattern (e.g., root/123456), the engine responds with a simulated Ubuntu welcome message and a prompt:

root@ubuntu:˜#

Up to five subsequent commands are accepted and individ-ually logged before the connection is gracefully terminated with a “server connection lost” message. Supported com-mands include ls, whoami, pwd, and attempts to invoke wget/curl (which return a simulated network failure). This design captures post-exploitation intent without exposing any real execution environment.

2. Engine 2 – Polymorphic Web Trap

The web engine, served via Gunicorn with four workers, implements polymorphic routing: the same running process switches its apparent identity based solely on the URL path requested.

• /wp-login.php renders a pixel-accurate WordPress

6.x login page (replacing the T-Pot Wordpot container).

• /phpmyadmin and /db/index.php render a ph-pMyAdmin 5.x login page (replacing the T-Pot php-MyAdmin container).
• Catch-all renders a corporate “Secure Employee Lo-gin” portal for all other paths.

Every   POST     payload          is          passed  through an analyze_request function that classifies the input:

Algorithm 1 Attack Classification (Web Engine)          

nput: raw string s (username + password concatenated) s ← lower(s)

if ${jndi: ∈ s then

return LOG4SHELL_EXPLOIT

else if ’ ∈ s or UNION SELECT ∈ s then return SQL_INJECTION

else if <script> ∈ s then

return XSS_ATTACK

else

return NORMAL_LOGIN

end if

When a SQL injection payload is detected, the engine returns a fabricated MySQL error message rather than a generic 401 response, simulating a vulnerable back end and encouraging the attacker to invest further effort—maximising dwell time and therefore intelligence yield. Log4Shell payloads embedded in HTTP headers (particularly User-Agent) are detected at the request middleware layer.

3. Engine 3 – Binary MySQL Handshake Trap

Standard Python socket libraries are used to listen on port 3306. Upon connection, the engine transmits a binary packet that faithfully reproduces the MariaDB 10.4 authentication handshake:

5.5.5-10.4.13-MariaDB

auth_plugin: mysql_native_password

This packet convinces database clients (DBeaver, HeidiSQL, mysql CLI) to submit an authentication response containing a hashed password. The engine logs the payload length and leading hex bytes of the response before issuing a standard MySQL Access Denied error (#28000).

4. Engine 4 – Windows SMB / Ransomware Trap

The SMB engine uses impacket.smbserver to ex-pose a writable share named FINANCE backed by a local

/app/captured_malware directory. On startup, a hon-eytoken file (CONFIDENTIAL_SALARIES.xlsx) is auto-matically written to the share. This serves a dual purpose: it attracts attackers seeking high-value data, and any access to the file constitutes unambiguous evidence of data-exfiltration intent.

SMB2 support is enabled (setSMB2Support(True)) and anonymous sessions are permitted, replicating a miscon-figured legacy Windows Server. Impacket’s internal logger is intercepted via a custom logging.Handler subclass that reformats connection, authentication, and file-transfer events into the project’s NDJSON schema.

5. Engine 5 – Dual-Protocol IoT / SCADA Trap

Two protocol listeners run concurrently inside a single con-tainer via asyncio.gather:

• MQTT (port 1883): An hbmqtt broker is config-ured with anonymous authentication enabled, mimick-ing an unsecured IoT message bus (webcams, smart thermostats, building management systems). Any client subscribing to or publishing on any topic is logged.
• Modbus TCP (port 502): A raw async server accepts

connections and returns the Modbus exception response 0x01 (Illegal Function), the standard reply from a Siemens S7-1200 PLC when queried by an unautho-rised host. The full hex payload of every inbound Modbus PDU is logged for offline analysis.

This engine replaces the T-Pot Conpot and AdbHoney containers in a single, 50 MB Python process, compared to the approximately 500 MB Docker layer for Conpot alone.

5. Threat-Intelligence Dashboard

The dashboard is a single-page HTML/JavaScript application served by Nginx. It polls all sensor NDJSON log files every two seconds using the Fetch API with cache-busting query parameters (?t=Date.now()) to ensure fresh data on every cycle. Chart.js renders a doughnut chart of attack distribution by sensor, and a reverse-chronological event feed displays the most recent fifty events with colour-coded attack classifications.

TABLE 2. Engine Throughput Under Concurrent Load

Four KPI cards provide at-a-glance situational awareness: Total Attacks, Unique Attacker IPs, Malware Payloads Cap-tured, and Most Active Sensor. The dark-mode design palette with green-on-black typography was deliberately chosen to signal the security-operations context to evaluators.

6. Experimental Evaluation

1. Test Environment

All experiments were conducted on a Kali Linux 2024.1 virtual machine (4 vCPUs, 8 GB RAM) running on an Intel Core i5 host. Docker Engine 24.x and Docker Compose v2 were used throughout.

2. Concurrency Stress Test

A simulated botnet was constructed using a Bash loop that spawned simultaneous curl, ssh, nc, and smbclient processes against all five engine ports. The loop was stepped from 10 to 5,000 concurrent connections. Table 2 sum-marises the results.

No engine crashes or missed events were observed below 5,000 connections. Above this threshold the SMB engine—which uses blocking threading internally via Impacket—became the bottleneck, accounting for approximately 70 per-cent of latency increase.

3. Memory Comparison with T-Pot

A reference T-Pot 24.x installation (Cowrie + Dionaea + Conpot + Snare/Tanner + phpMyAdmin containers only, excluding Elasticsearch) consumed 4.2 GB of RAM at idle. Project Mimic consumed 511 MB under 5,000 concur-rent connections—an 87.8 percent reduction for equivalent attack-surface coverage.

4. Fingerprinting Resistance

An Nmap version scan (nmap -sV) against the Project Mimic host returned:

• Port 2222: OpenSSH 8.2p1 (Ubuntu)
• Port 3306: MySQL 5.5.5
• Port 445: Windows File Sharing

None of the services were identified as honeypots. By con-trast, the same scan against a default T-Pot installation cor-rectly identifies several containers due to predictable banner patterns documented in public threat-intelligence databases.

TABLE 3. 48-Hour Public Deployment – Captured Events