HIVE-OT: Design, Implementation, and Reproducible Evaluation of a Process-Coupled Industrial Honeypot
This paper presents the design, implementation, and reproducible evaluation of HIVE-OT, a process-coupled industrial honeypot that validates its engineering through protocol regression testing and historical event analysis while explicitly acknowledging limitations in establishing full-platform reproducibility or physical fidelity.
Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
In the world of industrial control, massive machines like water treatment plants or power grids rely on a constant stream of digital instructions to keep running safely. These instructions travel over networks using specific languages, or protocols, that tell pumps when to start and valves when to close. To protect these critical systems from hackers, security experts often deploy digital traps known as honeypots. These are fake versions of real industrial systems, designed to look exactly like the genuine article to an attacker. When a hacker interacts with the trap, the system records every move, hoping to learn how the intruder thinks and what tools they use. However, building a convincing trap is difficult. If the fake system does not react realistically to commands, or if the records it keeps are incomplete, security teams cannot trust the data they collect. The core challenge is ensuring that when a command is sent, the system not only says it received it, but also accurately records what actually happened inside the machine as a result.
A team of researchers set out to build and test a new kind of industrial honeypot called HIVE-OT, specifically designed to track the chain of events from a received command to the actual change in the simulated machine. Their goal was to evaluate the evidence supported by the system's process-coupled research core and historical exports, distinguishing between the documented platform and a local implementation. They constructed a digital model of a water treatment process, complete with tanks, pumps, and filters, and connected it to a network interface that speaks the Modbus language, a standard used in many real factories. The researchers then ran a series of controlled experiments where they sent commands to this fake plant. They wanted to see if the system could distinguish between simply acknowledging a message and actually executing the physical action the message requested. In one set of tests, they deliberately told the system to accept a command but to ignore the part that would change the water flow. They found that without a specific type of final check, the system's logs would look identical whether the water flow changed or stayed the same. This meant that a standard log entry could not tell an analyst if the command had truly worked or if it had been silently ignored.
To solve this, the team designed a system that records three distinct things for every interaction: the command that was asked for, the system's immediate reply, and a final readout of the machine's actual state after the command was processed. By comparing these three pieces of information, they could see exactly what happened. In their tests, they ran sixty different scenarios where they sent the same commands but changed whether the machine actually moved or stayed still. They discovered that if they only looked at the initial request and the system's "okay" message, they could not tell the difference between a successful action and a failed one. However, when they added the final readout of the machine's state to their records, the difference became clear. This proved that for a honeypot to be truly useful, it must capture the final outcome, not just the conversation.
The researchers also looked at the massive amounts of data collected from a real-world deployment of this honeypot, which had been running on the internet for months. They compared two large sets of records from this deployment, one from July and a larger one from September. They found that while the total number of recorded events more than tripled, jumping from about 274,000 to over 842,000, the number of records that actually contained useful data did not grow at all. Both sets contained exactly 77,865 records with actual content. This meant that the newer, larger dataset was mostly filled with empty shells, and the percentage of useful data dropped significantly. The researchers also noted that the records lacked crucial details like session identifiers, which are needed to link different actions to a single attacker. Without these links, it is impossible to reconstruct a full story of an attack or to prove that a specific command actually changed the state of a machine.
The study concludes that while the HIVE-OT system successfully demonstrated a documented engineering design, an inspectable implementation, and reproducible evaluation artifacts regarding local software behavior and exported data, it does not establish full-platform reproducibility, cross-protocol consistency, physical fidelity, or defensive superiority. The system works well as a research tool to understand how to record evidence correctly, but the data it produced in the wild cannot be used to definitively prove who attacked the system or what physical damage they caused. The researchers emphasize that simply having a large volume of data does not make it better; if the data lacks the right connections and final state checks, it cannot answer the most important questions about an attack. Their work serves as a blueprint for building better traps in the future, showing that the value of a honeypot lies not in how many alerts it generates, but in how clearly it can show the difference between a request and a result.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.