PLC Honeypots: Enhancing Interaction-Level Assessment

Abstract

The motivation for this work arose when noticing that honeypot interaction-level definitions are mainly based on the information technology (IT) environment and do not reflect operational technology (OT), even though several honeypot projects target this field. Within OT, programmable logic controllers (PLCs) play a main role, so researchers often mimic this device at a certain interaction level — yet definitions of interaction level approaching PLCs are scarce.

This work adapts the IT definition of interaction level to encompass PLCs and their specific features. Through a nonsystematic literature review of 41 papers, features were mapped under honey system, honey service, and honey token perspectives, yielding a metrics proposal for low and high interaction: system (vendor-specific firmware, unique device banner, realistic network topology); service (industrial and network-management protocols, response times, code interactions, dynamic I/O, process simulation, web interface); token (PLC program files, MIB files, software licenses). Researchers can use these metrics to design PLC honeypots or select tools matching their target interaction level.

1. Introduction

The U.S. National Institute of Standards and Technology (NIST) defines deception as misleading, confusing, hiding critical assets from, or exposing covertly tainted assets to the adversary [1]. Honeypots — security resources whose value lies in being probed, attacked, or compromised — date back to the late 1980s, when Cliff Stoll, a student helping maintain his university computer network, noticed attackers breaking in and modifying programs for password stealing [2]. Since then, deception tools have spread to industrial control systems (ICSs) across all sectors, where their use in critical infrastructures amplifies the attacks targeting them.

In OT environments, ICSs use specialised automation and control equipment with distinct solution architectures, often communicating through industrial protocols designed without security in mind [3]. The programmable logic controller (PLC) — the device holding the process logic for automation and control tasks, with operator interfaces at several levels [4] — is therefore a likely attacker target. Researchers gain insight into attacker–PLC interactions by deploying decoy systems imitating a PLC with comparable services. This study investigates PLC honeypots and maps what is usually mimicked at low and high interaction types, structured in six sections with methods in Section 2, background in Section 3, results in Section 4, and discussion in Section 5.

2. Materials and Methods

This study rests on journal and conference articles, books, technology websites, the Conpot GitHub repository, and the OpenPLC software — the former feeding the background, the latter two grounding the discussion and metric application. Its core is a nonsystematic literature review driven by one research question: what are the explicit and implicit PLC features usable for classifying the interaction level of PLC honeypots?

Explicit metrics were counted when authors defined the interaction level or deliberately compared high- and low-interaction honeypots; implicit metrics when features were discussed via realism, credibility, and deception capability affecting attacker interaction. Features were mapped under the honey system, honey service, and honey token perspectives (Section 3) to preserve the IT definition's structure that most related work references. Using Google Scholar and Scopus with keyword combinations (honeypot, honeynet, PLC, programmable logic controller, interaction level, operational technology), 41 papers were collected — surveys and single use cases alike — of which 16 addressed features identifiable as explicit or implicit metrics answering the research question (Figure 1).

3. Background

One of the first formal honeypot definitions came from Lance Spitzner, founder of the Honeynet Project (1999): a security resource whose value lies in being probed, attacked, or compromised [5]. Honeypots emulate well-known systems, services, or data configured to look vulnerable, diverting attackers, collecting activity information, or holding intruders for documentation and response [6]. Originally production honeypots guarded real networks while research honeypots observed attackers off-network [2]; honeynets combine multiple honeypots, though the term is used inconsistently [7]. By what is mimicked, honeypots divide into honey system (an OS and its services, e.g. an Ubuntu system), honey service (software/protocols, e.g. HTTP, SSH, SMB), and honey token (data, e.g. a Word document) [2]. Low-interaction honeypots emulate without granting OS access — narrow scope but safer and detection-oriented (timestamps, source IPs, ports) — while high-interaction honeypots expose a real OS, usually in a sandboxed VM, capturing far richer attacker behaviour at higher risk and cost [5].

PLCs are industrial components built for real-time production environments, favouring efficiency and availability, and hence rely on customised rather than commercial operating systems [8]. Their main components are power supply, CPU, communication and I/O modules (Figure 2), executing cyclically in three stages — input sampling, program execution, output refresh — within strict cycle times whose violation causes malfunctions, making typical response times a relevant fidelity feature. Programming follows IEC 61131-3 languages (LD, SFC, FBD, ST, IL) [9]. Per the Purdue model [10], PLCs sit between level 0 (production process) and level 2 (supervision) (Figure 3), speaking serial and TCP/IP protocols — Modbus, Profibus, Profinet, OPC UA, IEC 60870-5, IEC 61850 [11,12] — plus proprietary ones such as S7comm, HSDS, and SRTP. PLC attack vectors span engineering workstations, HMIs, rogue devices, USB media, and controller networks, with methods from protocol exploitation and replay to code injection, threatening process manipulation, controller faults, and plant shutdown [8] (Table 1).

Decoy systems exist across IT and OT, but OT honeypot research rarely structures findings by interaction level the way IT work does. Section 3.4 reviews OT honeypot related work — from firmware-counterfeiting studies [17] and OS-fingerprinting considerations [18] to high-interaction physical PLC frameworks [19], ICS honeynets [20], cloud-deployment deception effects [22], ICSpot [23], Mimepot [24], Shodan-exposure studies [25], distributed Dipot systems [27], S7commTrace [28], early-detection IDS hybrids [29,31], realistic plant reports [30], virtual-PLC designs [32], HoneyPLC [35], Conpot [36,37], and OpenPLC [38] — showing a fragmented field this work's metrics aim to unify.

4. Results

The 16 metric-bearing papers (Table 2) were distilled into PLC-specific features across the three honeypot perspectives. System features concern what machine the attacker believes they face: firmware images and OS-fingerprint simulation, customizable fingerprints, network topology and configuration, fingerprint resistance, firewalls, and ring topologies. Service features — the richest category — span SSH/Telnet/DNS/NTP/FTP/HTTP/SNMP banners and authentication, Modbus TCP, S7comm, IEC 104, DNP3, GOOSE, MMS, STEP7, PLC program services (compile, interpret, load), function-code coverage, response latencies, Nmap scan behaviour, web interfaces, plant and process simulation, dynamic I/O updates, operator-interaction simulation, and traffic emulation. Token features comprise PLC program files, fake file servers, company/employee profiles, HMI software, PLC programs, and control logic. Deployment spans Docker, AWS cloud, local VMs, emulated and real equipment [7,16,3,15].

From these, the classification proposal (Table 3) sets explicit low/high thresholds. System: low means generic firmware, no unique banner, no topology simulation; high means vendor-specific firmware, a unique device banner, and simulated network topology. Service: low covers only basic industrial-protocol functions, basic network-management functions, and static I/O; high additionally requires covering 70% of common attack-vector moves, extended network-management functions, appropriate response times, PLC code-related interactions, dynamic I/O processing, physical process simulation, a web interface, and human-operator simulation. Token: low offers no fake files; high provides real and/or fake automation artefacts — PLC programs, MIB files, sensor/actuator manuals, software licences.

Physical versus virtual deployment (Section 4.1.4) cross-cuts the classification: virtualization (Docker, VMs, cloud) lowers cost and scales deception infrastructure but risks fingerprintable artefacts (hypervisor banners, cloud IP ranges, timing anomalies) that betray the decoy [22], while physical deployment maximises credibility at high cost and risk — a trade-off the metrics make explicit rather than hiding inside vague low/high labels.

5. Discussion

Conpot [36,37] — the most widely deployed ICS honeypot — ships a default Siemens S7-200 template (Figures 5, 7, 8) with Modbus function-code coverage visualised against the protocol specification (Figure 6, [34]). Scored against the metrics (Table 4), Conpot provides extended network-management protocol simulation and a web interface, but no unique banner, no topology simulation, no vendor-specific firmware, no 70%-coverage industrial-protocol simulation, no appropriate response-time modelling, no PLC-code interactions, no dynamic I/O, no process simulation, and no fake files: a solid low-interaction profile whose limits the metrics expose precisely.

OpenPLC [38] — open-source PLC software with an editor (Figure 9, Traffic Light FBD sample) — inverts the picture: vendor-specific firmware behaviour, appropriate response times, PLC-code interactions, physical process simulation, a web interface, and fake automation files score positively, while unique banners, topology simulation, full attack-vector protocol coverage, extended network-management functions, dynamic I/O, and operator simulation remain absent. The pair demonstrates the metrics' practical value: instead of debating whether Conpot or OpenPLC is low or high interaction in the abstract, adopters can read off exactly which deceptions each delivers and select — or combine — tools matching their target interaction level.

6. Conclusions

This work translated the IT-rooted low/high interaction vocabulary into PLC-native terms. The resulting metrics — system (firmware, banner, topology), service (protocols, timing, code, I/O, process, web, operator), token (automation files) — give researchers a concrete checklist for designing PLC honeypots at a deliberate interaction level and for auditing existing tools, replacing impressionistic labels with verifiable feature claims.

Applied to Conpot and OpenPLC, the metrics confirm complementary low-interaction strengths and pinpoint exactly what each lacks for high interaction. Future work should extend the metrics with empirical attacker-engagement measurements, cover additional PLC vendors and protocols, and validate thresholds — such as the 70% attack-vector coverage rule — against captured adversary sessions in the wild.