Another industrial cybersecurity firm dismissed ZionSiphon, the OT (operational technology) malware purportedly designed to sabotage Israeli water desalination plants, as a non-functional mock-up rather than a credible threat. Nozomi Networks Labs, after a detailed technical review of the sample, found multiple functionality inconsistencies, incomplete execution paths, and limited understanding of how industrial plants work, concluding it is likely a mock-up or non-functional proof of concept, possibly created to simulate malicious behavior rather than carry out real-world attacks.
Among the technical red flags, Nozomi found no real-world references to the hardcoded configuration filenames in the malware, which appeared to be fabricated and resembled the kind of generic output an LLM (large language model) might produce when asked to suggest configuration paths for a water desalination plant. This is consistent with Dragos’ assessment that the code was AI-generated. The sample also includes a flawed geofencing function that attempts to determine the host’s geolocation using the network interface’s local IP address, checked against hardcoded IP ranges, a method that would not work in NATed environments, where most real-world industrial systems operate.
“Our analysis of the ZionSiphon sample finds no evidence of a credible capability to operate against real-world OT environments,” Nozomi researchers wrote in a Friday blog post. “While the code is structured to resemble industrial malware, its implementation lacks the coherence, domain awareness, and precision required to achieve meaningful physical impact. The inconsistencies, incomplete logic, and unrealistic assumptions highlighted throughout this analysis point to a constructed or experimental artifact rather than a functional threat.”
“Based on our analysis of ZionSiphon, several features appear unrealistic and inconsistent with real-world water treatment operations. While individual functions are relatively clear in intent, a broader review of the sample reveals gaps that raise questions about how the components fit together,” according to the post. “There are no real-world references to the hardcoded configuration filenames as they seem to be fabricated and resembling the kind of generic output an LLM might produce when asked to suggest configuration paths for a water desalination plant. The formats of the configuration filenames vary greatly (some are .ini, others .dat or .cfg or .conf), yet the function responsible for modifying them handles all of them in the exact same way.”
Nozomi disclosed that the sample includes a function to ensure that it only executes in Israel, which is the target country. “The function tries to determine the host’s geolocation by retrieving the network interface’s local IP address and then checking it against hardcoded IP ranges associated with the target country. Malware typically relies on external services to determine the host’s public IP address, as this method would not work in NATed environments.”
“Previously observed OT malware typically includes configurations that tailor its operation to the specific target environment,” according to the post. “For example, Industroyer2 embeds network-specific parameters such as IP addresses, ports, and IEC-104 details, including Information Object Addresses, while the original Industroyer relies on an external .ini file to customize its behavior. Achieving physical impact requires precise mappings between protocol values and the underlying physical processes, which vary across vendors and installations.”
In contrast, the analyzed sample attempts to modify parameters such as ‘chlorine level’ and ‘turbine speed’ dynamically by querying Modbus registers at runtime and inferring their meaning based solely on numeric ranges.
Apart from the malware’s multiple technical faults, “its operational logic does not align with the reality of how water and desalination plants operate. It’s not as simple as setting a MAX value on a Chlorine control point via a config file or Modbus command.”
Nozomi added that real control systems don’t typically read process setpoints from flat files at runtime. “For the Modbus writes to be effective, the malware would need to know the exact register addresses for chlorine dose and pressure setpoints at the specific target facility. Modbus has no directory service. There is no ‘chlorine setpoint register’ that is standardized across vendors. The author would need facility-specific documentation or prior reconnaissance to write to the correct registers.”
The researchers added that “even with all this in place, there are still physical limitations on the system as well as the safety engineering and safety systems. On the physical side, pumps are sized for the normal operating range. Chemical metering pumps are designed with sufficient capacity to dose at peak flow conditions while maintaining sufficient turn-down to avoid overdosing during low-flow periods. They are not oversized, as this adds cost and complexity. A pump designed to deliver 2 ppm into a 10 Mgal/d flow cannot suddenly deliver 1000 ppm. The physics of pump stroke, speed, and chemical tank volume won’t allow it.”
On the safety side, there are water-quality monitoring systems, PLC logic, hardware interlocks, and most importantly, human operators who monitor these plants to keep our water safe. Good physical engineering should make even a working cyber attack of this type not impactful. Alongside operators, cyber defenders work to keep our water supply safe. While water cybersecurity is underfunded, some facilities have good security in place, and it’s safe to assume that some referenced sites in the malware are on that list, given past attacks and current geopolitical realities.
Underlining that ZionSiphon is demonstrative code, not a deployable threat, Nozomi recognizes that this does not diminish the importance of continued vigilance in the OT security space. “Sophisticated malware targeting industrial systems has demonstrated the level of planning and environment-specific knowledge required to succeed. In contrast, ZionSiphon illustrates how superficial indicators of malicious intent can be mistaken for operational capability when examined without sufficient technical context.”
It also noted that the widespread attention given to this sample underscores the need for careful validation and technical rigor when assessing potential threats. Distinguishing between demonstrative code and genuinely deployable tooling is critical to maintaining an accurate understanding of the threat landscape and avoiding unnecessary alarm.
Last week, Dragos pushed back against alarm over ZionSiphon, a piece of malware purportedly designed to sabotage Israeli water desalination facilities, calling it a poor attempt at generating OT malware using an LLM whose code is broken and shows little to no knowledge of dam desalination or ICS protocols. Dragos said the malware would fail to cause any significant negative consequence in an OT environment and is not a credible threat to dam desalination facilities or any critical infrastructure, a direct rebuttal to Darktrace’s analysis, which Dragos says mistakenly overstated ZionSiphon’s disruptive potential.
