ZionSiphon: OT malware against Israeli water supply
On 16 April 2026 Darktrace published an analysis of malware called ZionSiphon, aimed at Israeli water and desalination plants. Dragos had examined the sample in March and reads ZionSiphon as an immature attempt at OT malware, possibly written with the help of an LLM. As a single sample it is not threatening. What it says about the threat landscape is worth reading anyway.
Known techniques
The techniques in the sample are the ones familiar from classic infrastructure attacks: persistence through the registry, disguise as svchost.exe, and USB propagation through manipulated shortcuts. The malware uses no zero-days, so nothing out of the ordinary.
ZionSiphon implements parts of Modbus, DNP3 and S7comm. The Modbus implementation is the most developed; DNP3 and S7comm are barely there. Darktrace and Dragos both describe faulty implementations. Next to Incontroller/Pipedream or Industroyer, ZionSiphon is in a different league. Those tools came from teams with substantial resources and the protocols were implemented precisely. ZionSiphon reads more like an alpha version written by one person.
Why it is relevant anyway
Modbus is a widely used ICS protocol and is considered insecure: it provides neither authentication nor encryption. Plenty of open-source libraries let you read and write registers in a few lines of code. Protocols such as IEC 61850 are considerably more complex and harder to abuse. The bar for a working Modbus attack is low.
FrostyGoop showed that Modbus attacks work. In January 2024 that malware used Modbus TCP to manipulate ENCO controllers in a Ukrainian district heating plant. It used a publicly available Go library from GitHub and a JSON configuration file holding the target registers of the ENCO controllers. The register information it needed was publicly available in the vendor documentation.
Many vendor manuals contain detailed register tables. Which address controls which process value is written down in the documentation. Anyone who knows OSINT techniques can obtain that information. Attackers can also use LLMs to speed up development.
OT malware is not IT malware on OT systems
HMIs are regularly infected with ordinary IT malware, and the infections often go unnoticed for weeks or months. Because these systems are production-critical, they frequently keep running while infected.
OT-specific malware that talks to control systems directly is a different matter. It intervenes in physical processes, for example by changing setpoints in pump control or chemical dosing. If malware of that kind arrived in a mature form on OT systems that are already compromised, the possible damage would be considerable.
Many of these systems run no EDR and no current antivirus. Even simple Windows techniques go undetected there. In OT environments infections often arrive on USB sticks, because maintenance technicians move sticks between systems routinely, for software updates, configuration changes or data exports. Stuxnet already used that path to reach an isolated plant.
The bar for simple OT malware built on open protocols is dropping. Protocol documentation is freely available, libraries exist for several programming languages, and generative AI can speed development up. What ZionSiphon also shows is that the result does not automatically work. Effective, process-specific malware remains demanding. That makes the basics more important, not less: asset inventory, hardening, OT pentests, network segmentation and OT-specific security monitoring.
Sources: