{
	"id": "0657c964-91f0-4477-a15c-8bb95799cfa6",
	"created_at": "2026-05-06T02:02:57.380571Z",
	"updated_at": "2026-05-06T02:03:52.743234Z",
	"deleted_at": null,
	"sha1_hash": "58dec2758815caf7bd6ff770811a9b4d5184ebb7",
	"title": "Inside ZionSiphon: Darktrace’s Analysis of OT Malware Targeting Israeli Water Systems",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2063183,
	"plain_text": "Inside ZionSiphon: Darktrace’s Analysis of OT Malware Targeting\r\nIsraeli Water Systems\r\nBy Calum Hall\r\nPublished: 2026-04-16 · Archived: 2026-05-06 02:01:55 UTC\r\nWhat is ZionSiphon?\r\nDarktrace recently analyzed a malware sample, which identifies itself as ZionSiphon. This sample combines several familiar\r\nhost-based capabilities, including privilege escalation, persistence, and removable-media propagation, with targeting logic\r\nthemed around water treatment and desalination environments.\r\nThis blog details Darktrace’s investigation of ZionSiphon, focusing on how the malware identifies targets, establishes\r\npersistence, attempts to tamper with local configuration files, and scans for Operational Technology (OT)-relevant services\r\non the local subnet. The analysis also assesses what the code suggests about the threat actor’s intended objectives and\r\nhighlights where the implementation appears incomplete.\r\nFigure 1: Function “ZionSiphon()” used by the malware author.\r\nZionSiphon targets and motivations\r\nIsrael-Focused Targeting and Messaging\r\nThe clearest indicators of intent in this sample are its hardcoded Israel-focused targeting checks and the strong political\r\nmessaging found in some strings in the malware’s binary.\r\nIn the class initializer, the malware defines a set of IPv4 ranges, including “2.52.0.0-2.55.255.255”, “79.176.0.0-\r\n79.191.255.255”, and “212.150.0.0-212.150.255.255”, indicating that the author intended to restrict execution to a narrow\r\nrange of addresses. All of the specified IP blocks are geographically located within Israel.\r\nFigure 2: The malware obfuscates the IP ranges by encoding them in Base64.\r\nThe ideological motivations behind this malware are also seemingly evident in two Base64-encoded strings embedded in the\r\nbinary. The first (shown in Figure 1) is:\r\n“Netanyahu =\r\nSW4gc3VwcG9ydCBvZiBvdXIgYnJvdGhlcnMgaW4gSXJhbiwgUGFsZXN0aW5lLCBhbmQgWWVtZW4gYWdhaW5zdCBaaW9uaXN0IGFnZ3Jlc3Npb24uI\r\nwhich decodes to “In support of our brothers in Iran, Palestine, and Yemen against Zionist aggression. I am \"0xICS\".\r\nThe second string, “Dimona = UG9pc29uaW5nIHRoZSBwb3B1bGF0aW9uIG9mIFRlbCBBdml2IGFuZCBIYWlmYQo=“,\r\ndecodes to “Poisoning the population of Tel Aviv and Haifa”.  These strings do not appear to be used by the malware for any\r\nhttps://www.darktrace.com/blog/inside-zionsiphon-darktraces-analysis-of-ot-malware-targeting-israeli-water-systems\r\nPage 1 of 9\n\noperational purpose, but they do offer an indication of the attacker’s motivations. Dimona, referenced in the second string, is\r\nan Israeli city in the Negev desert, primarily known as the site of the Shimon Peres Negev Nuclear Research Center.\r\nFigure 3: The Dimona string as it appears in the decompiled malware, with the Base64-decoded text.\r\nThe hardcoded IP ranges and propaganda‑style text suggest politically motivated intent, with Israel appearing to be a likely\r\ntarget.\r\nWater and desalination-themed targeting?\r\nThe malware also includes Israel-linked strings in its target list, including “Mekorot, “Sorek”, “Hadera”, “Ashdod”,\r\n“Palmachim”, and “Shafdan”. All of the strings correspond to components of Israel’s national water infrastructure: Mekorot\r\nis Israel’s national water company responsible for managing the country’s water system, including major desalination and\r\nwastewater projects. Sorek, Hadera, Ashdod, and Palmachim are four of Israel’s five major seawater desalination plants,\r\neach producing tens of millions of cubic meters of drinking water annually. Shafdan is the country’s central wastewater\r\ntreatment and reclamation facility. Their inclusion in ZionSiphon’s targeting list suggests an interest in infrastructure linked\r\nto Israel’s water sector.\r\nFigure 4: Strings in the target list, all related to Israel and water treatment.\r\nBeyond geographic targeting, the sample contains a second layer of environment-specific checks aimed at water treatment\r\nand desalination systems. In the function ”IsDamDesalinationPlant()”, the malware first inspects running process names\r\nfor strings such as “DesalPLC”, “ROController”, “SchneiderRO”, “DamRO”, “ReverseOsmosis”, “WaterGenix”,\r\n“RO_Pump”, “ChlorineCtrl”, “WaterPLC”, “SeaWaterRO”, “BrineControl”, “OsmosisPLC”, “DesalMonitor”,\r\n“RO_Filter”, “ChlorineDose”, “RO_Membrane”, “DesalFlow”, “WaterTreat”, and “SalinityCtrl”. These strings are\r\ndirectly related to desalination, reverse osmosis, chlorine handling, and plant control components typically seen in the water\r\ntreatment industry.\r\nThe filesystem checks reinforce this focus. The code looks for directories such as “C:\\Program Files\\Desalination”,\r\n“C:\\Program Files\\Schneider Electric\\Desal”, “C:\\Program Files\\IDE Technologies”, “C:\\Program Files\\Water\r\nTreatment”, “C:\\Program Files\\RO Systems”, “C:\\Program Files\\DesalTech”, “C:\\Program Files\\Aqua Solutions”,\r\nand “C:\\Program Files\\Hydro Systems”, as well as files including “C:\\DesalConfig.ini”, “C:\\ROConfig.ini”,\r\n“C:\\DesalSettings.conf”, “C:\\Program Files\\Desalination\\system.cfg”, “C:\\WaterTreatment.ini”,\r\n“C:\\ChlorineControl.dat”, “C:\\RO_PumpSettings.ini”, and “C:\\SalinityControl.ini.”\r\nPrivilege Escalation\r\nhttps://www.darktrace.com/blog/inside-zionsiphon-darktraces-analysis-of-ot-malware-targeting-israeli-water-systems\r\nPage 2 of 9\n\nFigure 5: The “RunAsAdmin” function from the malware sample.\r\nThe malware’s first major action is to check whether it is running with administrative rights. The “RunAsAdmin()” function\r\ncalls “IsElevated()”, which retrieves the current Windows identity and checks whether it belongs to the local Administrators\r\ngroup. If the process is already elevated, execution proceeds normally.\r\nFigure 6: The “IsElevated” function as seen in the sample.\r\nIf not, the code waits on the named mutex and launches “powershell.exe” with the argument “Start-Process -FilePath\r\n\u003ccurrent executable\u003e -Verb RunAs”, after which it waits for that process to finish and then exits. \r\nPersistence and stealth installation\r\nFigure 7: Registry key creation.\r\nPersistence is handled by “s1()”. This routine opens “HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run”,\r\nretrieves the current process path, and compares it to “stealthPath”. If the current file is not already running from that\r\nlocation, it copies itself to the stealth path and sets the copied file’s attributes to “hidden”.\r\nThe code then creates a “Run” value named “SystemHealthCheck” pointing to the stealth path. Because “stealthPath” is\r\nbuilt from “LocalApplicationData” and the hardcoded filename “svchost.exe”, the result is a user-level persistence\r\nmechanism that disguises the payload under a familiar Windows process name. The combination of a hidden file and a\r\nplausible-sounding autorun value suggests an intent to blend into ordinary Windows artifacts rather than relying on more\r\ncomplex persistence methods.\r\nTarget determination\r\nThe malware’s targeting determination is divided between “IsTargetCountry()” and “IsDamDesalinationPlant()”. The\r\n“IsTargetCountry()” function retrieves the local IPv4 address, converts it to a numeric value, and compares it against each\r\nhttps://www.darktrace.com/blog/inside-zionsiphon-darktraces-analysis-of-ot-malware-targeting-israeli-water-systems\r\nPage 3 of 9\n\nof the hardcoded ranges stored in “ipRanges”. Only if the address falls within one of these ranges does the code move on to\r\nnext string-comparison step, which ultimately determines whether the country check succeeded.\r\nFigure 8: The main target validation function.\r\nFigure 9 : The “IsTargetCountry” function.\r\n“IsDamDesalinationPlant()” then assesses whether the host resembles a relevant OT environment. It first scans running\r\nprocess names for the hardcoded strings previously mentioned, followed by checks for the presence of any of the hardcoded\r\ndirectories or files. The intended logic is clear: the payload activates only when both a geographic condition and an\r\nenvironment specific condition related to desalination or water treatment are met.\r\nhttps://www.darktrace.com/blog/inside-zionsiphon-darktraces-analysis-of-ot-malware-targeting-israeli-water-systems\r\nPage 4 of 9\n\nFigure. 10: An excerpt of the list of strings used in the “IsDamDesalinationPlant” function\r\nWhy this version appears dysfunctional\r\nAlthough the file contains sabotage, scanning, and propagation functions, the current sample appears unable to satisfy its\r\nown target-country checking function even when the reported IP falls within the specified ranges. In the static constructor,\r\nevery “ipRanges” entry is associated with the same decoded string, “Nqvbdk”, derived from “TnF2YmRr”. Later,\r\n“IsTargetCountry()” (shown in Figure 8) compares that stored value against “EncryptDecrypt(\"Israel\", 5)”.\r\nFigure 11: The “EncryptDecrypt” function\r\nAs implemented, “EncryptDecrypt(\"Israel\", 5)” does not produce “Nqvbdk”, it produces a different string. This function\r\nseems to be a basic XOR encode/decode routine, XORing the string “Israel” with value of 5. Because the resulting output\r\ndoes not match “Nqvbdk” the comparison always fails, even when the host IP falls within one of the specified ranges. As a\r\nresult, this build appears to consistently determine that the device is not a valid target. This behavior suggests that the\r\nversion is either intentionally disabled, incorrectly configured, or left in an unfinished state. In fact, there is no XOR key that\r\nwould transform “Israel” into “Nqvbdk” using this function.\r\nSelf-destruct function\r\nhttps://www.darktrace.com/blog/inside-zionsiphon-darktraces-analysis-of-ot-malware-targeting-israeli-water-systems\r\nPage 5 of 9\n\nFigure 12: The “SelfDestruct” function\r\nIf IsTargetCountry() returns false, the malware invokes “SelfDestruct()”. This routine removes the SystemHealthCheck\r\nvalue from “HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run”, writes a log file to\r\n“%TEMP%\\target_verify.log” containing the message “Target not matched. Operation restricted to IL ranges. Self-destruct initiated.” and creates the batch file “%TEMP%\\delete.bat”. This file repeatedly attempts to delete the malware’s\r\nexecutable, before deleting itself.\r\nLocal configuration file tampering\r\nIf the malware determines that the system it is on is a valid target, its first action is local file tampering.\r\n“IncreaseChlorineLevel()” checks a hardcoded list of configuration files associated with desalination, reverse osmosis,\r\nchlorine control, and water treatment OT/Industrial Control Systems (ICS).  As soon as it finds any one of these file present,\r\nit appends a fixed block of text to it and returns immediately.\r\nFigure 13: The block of text appended to relevant configuration files.\r\nThe appended block of text contains the following entries: “Chlorine_Dose=10”, “Chlorine_Pump=ON”,\r\n“Chlorine_Flow=MAX”, “Chlorine_Valve=OPEN”, and “RO_Pressure=80”. Only if none of the hardcoded files are\r\nfound does the malware proceed to its network-based OT discovery logic.\r\nOT discovery and protocol logic\r\nThis section of the code attempts to identify devices on the local subnet, assign each one a protocol label, and then attempt\r\nprotocol-specific communication. While the overall structure is consistent across protocols, the implementation quality\r\nvaries significantly.\r\nhttps://www.darktrace.com/blog/inside-zionsiphon-darktraces-analysis-of-ot-malware-targeting-israeli-water-systems\r\nPage 6 of 9\n\nFigure 14: The ICS scanning function.\r\nThe discovery routine, “UZJctUZJctUZJct()”, obtains the local IPv4 address, reduces it to a /24 prefix, and iterates across\r\nhosts 1 through 255. For each host, it probes ports 502 (Modbus), 20000 (DNP3), and 102 (S7comm), which the code\r\nlabels as “Modbus”, “DNP3”, and “S7” respectively if a valid response is received on the relevant port.\r\nThe probing is performed in parallel. For every “ip:port” combination, the code creates a task and attempts a TCP\r\nconnection. The “100 ms” value in the probe routine is a per-connection timeout on “WaitOne(100, ...)”, rather than a delay\r\nbetween hosts or protocols. In practice, this results in a burst of short-lived OT-focused connection attempts across the local\r\nsubnet.\r\nProtocol validation and device classification\r\nWhen a connection succeeds, the malware does not stop at the open port. It records the endpoint as an “ICSDevice” with an\r\nIP address, port, and protocol label. It then performs a second-stage validation by writing a NULL byte to the remote stream\r\nand reading the response that comes back.\r\nFor Modbus, the malware checks whether the first byte of the reply is between 1 and 255, for DNP3, it checks whether the\r\nfirst two bytes are “05 64”, and for S7comm, it checks whether the first byte is “03”. These checks are not advanced parsers,\r\nbut they do show that the author understood the protocols well enough to add lightweight confirmation before sending\r\nfollow-on data.\r\nFigure 15: The Modbus read request along with unfinished code for additional protocols.  \r\nThe most developed OT-specific logic is the Modbus-oriented path. In the function “IncreaseChlorineLevel(string\r\ntargetIP, int targetPort, string parameter)”, the malware connects to the target and sends “01 03 00 00 00 0A”. It then\r\nreads the response and parses register values in pairs. The code then uses some basic logic to select a register index: for\r\n“Chlorine_Dose”, it looks for values greater than 0 and less than 1000; for “Turbine_Speed”, it looks for values greater\r\nthan 100.\r\nThe Modbus command observed in the sample (01 03 00 00 00 0A) is a Read Holding Registers request. The first byte\r\n(0x01) represents the unit identifier, which in traditional Modbus RTU specifies the addressed slave device; in Modbus TCP,\r\nhowever, this value is often ignored or used only for gateway routing because device addressing is handled at the IP/TCP\r\nlayer.\r\nThe second byte (0x03) is the Modbus function code indicating a Read Holding Registers request. The following two bytes\r\n(0x00 0x00) specify the starting register address, indicating that the read begins at address zero. The final two bytes (0x00\r\n0A) define the number of registers to read, in this case ten consecutive registers. Taken together, the command requests the\r\ncontents of the first ten holding registers from the target device and represents a valid, commonly used Modbus operation.\r\nhttps://www.darktrace.com/blog/inside-zionsiphon-darktraces-analysis-of-ot-malware-targeting-israeli-water-systems\r\nPage 7 of 9\n\nIf a plausible register is found, the malware builds a six-byte Modbus write using function code “6” (Write)” and sets the\r\nvalue to 100 for “Chlorine_Dose”, or 0 for any other parameter. If no plausible register is found, it falls back to using\r\nhardcoded write frames. In the main malware path, however, the code only calls this function with “Chlorine_Dose\".\r\nIf none of the ten registers meets the expected criteria, the malware does not abandon the operation. Instead, it defaults to a\r\nset of hardcoded Modbus write frames that specify predetermined register addresses and values. This behavior suggests that\r\nthe attacker had only partial knowledge of the target environment. The initial register-scanning logic appears to be an\r\nattempt at dynamic discovery, while the fallback logic ensures that a write operation is still attempted even if that discovery\r\nfails.\r\nIncomplete DNP3 and S7comm Logic\r\nThe DNP3 and S7comm branches appear much less complete. In “GetCommand()”, the DNP3 path returns the fixed byte\r\nsequence “05 64 0A 0C 01 02”, while the S7comm path returns “03 00 00 13 0E 00”. Neither sequence resembles a fully\r\nformed command for the respective protocol.\r\nIn the case of the S7comm section, the five byte‑ sequence found in the malware sample (05 00 1C 22 1E) most closely\r\nmatches the beginning of an S7comm parameter block, specifically the header of a “WriteVar (0x05)” request, which is the\r\nS7comm equivalent of a Modbus register write operation. In the S7comm protocol, the first byte of a parameter block\r\nidentifies the function code,  but the remaining bytes in this case do not form a valid item definition. A vaild S7 WriteVar\r\nparameter requires at least one item and a full 11-byte variable-specification structure. By comparison this 5‑ byte array is\r\nfar too short to be a complete or usable command.\r\nThe zero item count (0x00) and the trailing three bytes appear to be either uninitialized data or the beginning of an\r\nincomplete address field. Together, these details suggest that the attacker likely intended to implement S7 WriteVar\r\nfunctionality, like the Modbus function, but left this portion of the code unfinished.\r\nThe DNP3 branch of the malware also appears to be only partially implemented. The byte sequence returned by the DNP3\r\npath (05 64 0A 0C 01 02) begins with the correct two‑byte DNP3 link‑layer sync header (0x05 0x64) and includes\r\nadditional bytes that resemble the early portion of a link‑layer header. However, the sequence is far too short to constitute a\r\nvalid DNP3 frame. It lacks the required destination and source address fields, the 16‑bit CRC blocks, and any\r\napplication‑layer payload in which DNP3 function code would reside. As a result, this fragment does not represent a\r\nmeaningful DNP3 command.\r\nThe incomplete S7 and DNP3 fragments suggest that these protocol branches were still in a developmental or experimental\r\nstate when the malware was compiled. Both contain protocol‑accurate prefixes, indicating an intent to implement\r\nmulti‑protocol OT capabilities, however for reasons unknow, these sections were not fully implemented or could not be\r\ncompleted prior to deployment.\r\nUSB Propagation\r\nThe malware also includes a removable-media propagation mechanism. The “sdfsdfsfsdfsdfqw()” function scans for drives,\r\nselects those identified as removable, and copies the hidden payload to each one as “svchost.exe” if it is not already present.\r\nThe copied executable is marked with the “Hidden” and “System” attributes to reduce visibility.\r\nThe malware then calls “CreateUSBShortcut()”, which uses “WScript.Shell” to create .lnk files for each file in the\r\nremovable drive root. Each shortcut’s TargetPath is set to the hidden malware copy, the icon is set to “shell32.dll, 4” (this is\r\nthe windows genericfile icon), and the original file is hidden. Were a victim to click this “file,” they would unknowingly run\r\nthe malware.\r\nFigure 14:The creation of the shortcut on the USB device.\r\nKey Insights\r\nhttps://www.darktrace.com/blog/inside-zionsiphon-darktraces-analysis-of-ot-malware-targeting-israeli-water-systems\r\nPage 8 of 9\n\nZionSiphon represents a notable, though incomplete, attempt to build malware capable of malicious interaction with\r\nOT systems targeting water treatment and desalination environments.\r\nWhile many of ZionSiphon’s individual capabilities align with patterns commonly found in commodity malware, the\r\ncombination of politically motivated messaging, Israel‑specific IP targeting, and an explicit focus on desalination‑related\r\nprocesses distinguishes it from purely opportunistic threats. The inclusion of Modbus sabotage logic, filesystem tampering\r\ntargeting chlorine and pressure control, and subnet‑wide ICS scanning demonstrates a clear intent to interact directly with\r\nindustrial processes controllers and to cause significant damage and potential harm, rather than merely disrupt IT endpoints.\r\nAt the same time, numerous implementation flaws, most notably the dysfunctional country‑validation logic and the\r\nplaceholder DNP3 and S7comm components, suggest that analyzed version is either a development build, a prematurely\r\ndeployed sample, or intentionally defanged for testing purposes. Despite these limitations, the overall structure of the code\r\nlikely indicates a threat actor experimenting with multi‑protocol OT manipulation, persistence within operational networks,\r\nand removable‑media propagation techniques reminiscent of earlier ICS‑targeting campaigns.\r\nEven in its unfinished state, ZionSiphon underscores a growing trend in which threat actors are increasingly experimenting\r\nwith OT‑oriented malware and applying it to the targeting of critical infrastructure. Continued monitoring, rapid anomaly\r\ndetection, and cross‑visibility between IT and OT environments remain essential for identifying early‑stage threats like this\r\nbefore they evolve into operationally viable attacks.\r\nCredit to Calum Hall (Cyber Analyst)\r\nEdited by Ryan Traill (Content Manager)\r\nReferences\r\n1.      \r\n https://www.virustotal.com/gui/file/07c3bbe60d47240df7152f72beb98ea373d9600946860bad12f7bc617a5d6f5f/details\r\nSource: https://www.darktrace.com/blog/inside-zionsiphon-darktraces-analysis-of-ot-malware-targeting-israeli-water-systems\r\nhttps://www.darktrace.com/blog/inside-zionsiphon-darktraces-analysis-of-ot-malware-targeting-israeli-water-systems\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.darktrace.com/blog/inside-zionsiphon-darktraces-analysis-of-ot-malware-targeting-israeli-water-systems"
	],
	"report_names": [
		"inside-zionsiphon-darktraces-analysis-of-ot-malware-targeting-israeli-water-systems"
	],
	"threat_actors": [],
	"ts_created_at": 1778032977,
	"ts_updated_at": 1778033032,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/58dec2758815caf7bd6ff770811a9b4d5184ebb7.pdf",
		"text": "https://archive.orkl.eu/58dec2758815caf7bd6ff770811a9b4d5184ebb7.txt",
		"img": "https://archive.orkl.eu/58dec2758815caf7bd6ff770811a9b4d5184ebb7.jpg"
	}
}