Building a Fake Solar Plant for Cybersecurity Research, Part 2

Most honeypots are easy to spot. They answer too fast, expose too many ports, and behave like nothing a real operator would ever deploy. Attackers who target industrial systems have learned to sniff these out in seconds, which is exactly why Ari Zhorzholiani's project is interesting. The goal in this second installment is not just to attract traffic, but to build something that survives scrutiny: a fake solar plant that talks like a real one.

The first part of the series laid the groundwork, standing up the environment and the supervisory layer. This part gets into the part that matters for anyone studying attacks against operational technology. It connects the simulated plant to industrial protocols, gives it the kind of internal logic a real facility would have, and starts collecting data on who interacts with it and how.

Why a solar plant, and why fake one at all

Renewable energy sites sit in an awkward security position. They are distributed, often remotely managed, and increasingly bolted onto grids that were never designed for this many internet-facing endpoints. A solar inverter farm has dozens of devices speaking Modbus, a protocol designed in 1979 with no authentication and no encryption. If you can reach the port, you can read registers and, in many deployments, write to them.

That makes solar a useful subject for a honeypot. It is realistic, it is a growing slice of critical infrastructure, and the attacks against it are not hypothetical. The research question is straightforward: when you put a believable solar plant on the public internet, who finds it, what do they do, and can you tell reconnaissance scans apart from someone who actually understands industrial control systems?

Making Modbus believable

The technical heart of the build is the Modbus layer. A real solar installation exposes registers that map to physical reality: DC voltage, AC output, inverter temperature, fault codes, grid frequency. A lazy honeypot returns static values or random noise, and that is the tell. An experienced attacker reads a register, comes back a few minutes later, and notices the panel temperature never changed even though the simulated sun supposedly moved across the sky.

So the registers have to breathe. The plant models a daily generation curve, ramps output as the simulated day progresses, lets inverter temperatures rise under load, and occasionally throws a plausible fault. The values are internally consistent, which is the property that separates a convincing decoy from an obvious trap. When an intruder writes to a setpoint register, the simulated plant responds the way real equipment would, shifting downstream readings instead of silently swallowing the command.

This is the difference between a honeypot that logs a port scan and one that records an actual interaction with control logic. The second kind tells you something about intent.

Mapping behavior to MITRE ATT&CK for ICS

Raw packet captures are not intelligence. To turn observed activity into something useful, the project leans on the MITRE ATT&CK for ICS matrix, which catalogs the techniques adversaries use specifically against industrial environments. A connection that enumerates Modbus function codes maps cleanly to a discovery technique. A write to a coil that would change an operational parameter maps to impair process control or manipulation of control.

Framing the data this way does two things. It makes the findings comparable to other published research instead of a pile of one-off logs, and it forces honesty about what was actually observed. Plenty of traffic that hits an exposed industrial port is indiscriminate scanning from services that index the entire internet. Tagging events against a known framework helps separate the background noise from the small number of sessions that show real understanding of what the device is.

What the trap is built to catch

The value of this kind of work is in the distribution of who shows up. The vast majority of contact with an internet-facing Modbus port comes from automated scanners cataloging the device. A smaller set probes a little further, pulling register values to fingerprint the equipment. A much smaller set still does something that suggests a human who knows the protocol is reading the plant's state and considering what a write would do.

That last group is the entire point. Threat intelligence on industrial attacks is thin compared to what exists for ordinary IT systems, partly because real operators understandably do not publish their incident data, and partly because the attacks are rarer and harder to study. A well-built decoy is one of the few ethical ways to watch the behavior without putting an actual grid asset at risk.

The honest limits

A honeypot tells you about the attackers who find it, not about the full population of threats, and self-selection cuts both ways. The most sophisticated actors may recognize a decoy and quietly leave, never generating the data you most want. Internet-wide scanners inflate the raw numbers and can make a quiet target look busier than it is. Anyone reading this research should treat it as a lens on a slice of activity rather than a census.

Those caveats do not diminish the work. They define it. The project is most useful as a method other researchers can reproduce and extend: a documented way to build a believable industrial decoy, instrument it against a recognized framework, and report what it sees without overclaiming. For a sector where defenders are still short on data, a repeatable approach to gathering it is worth more than any single sensational finding.

The series continues to be a practical read for anyone working on ICS security, IoT exposure, or the slow, necessary job of making renewable infrastructure as defensible as the grid it is feeding.