More bark than byte. [Research Saturday]

Summary

Podcast Summary: More Bark Than Byte – Zion Siphon OT Malware: First Attempts, Psyops, or Both?

CyberWire Daily – Research Saturday | June 27, 2026
Hosted by: Dave Bittner (N2K Networks)
Guest: Daniel Schwabi, Chief Information Security Officer & Head of Investigations, Domain Tools

---

Episode Overview

This episode delves into the analysis of a curious piece of malware dubbed "Zion Siphon," which ostensibly targeted Israeli water infrastructure. Host Dave Bittner and guest Daniel Schwabi break down the findings from Domain Tools’ latest research, scrutinizing both the technical shortcomings and the possible motivations—ranging from amateur malfeasance to deliberate psychological operations (psyops). The discussion critically explores the gap between intent and capability in cyberattacks targeting operational technology (OT), and offers practical defensive insights for industrial control system operators.

---

Key Discussion Points & Insights

1. Discovery and Initial Red Flags ([01:25]–[04:24])

• Unusually Direct Naming:
  The malware was named “SCADA security patch version 8.4.exe”—suspiciously generic and unlike genuine manufacturer patches (e.g., from Siemens).
  • Quote, Schwabi: “I've never come across any executable named something like that... This is not something I've ever come across.” ([03:44])
• Target Indicators:
  Metadata and code clues indicated a focus on Israeli water treatment facilities, with some named directly in the code.

2. Technical Analysis: A Malware That Can’t Bite ([06:09]–[11:16])

• Flawed Location Check:
  The malware included logic to check if it was running within Israeli IP space, executing only if true. However, a coding error (an XOR bug) rendered this logic inoperable—the malware would never execute as intended.

  • Schwabi: “There's a flaw in that logic where the... part will never be true. It's an XOR bug, and basically it never has a chance to run...” ([06:20])
  • Bittner: “Does this mean that this may have never successfully executed in its intended geographic region?”
    Schwabi: “This is what we believe... [it] had no chance to ever work.” ([07:12])

• Limited Capability:
  Even if the location check succeeded, the malware had no means to interact with industrial controllers (PLCs). It could only write configuration files on a Windows host—requiring further manual intervention to achieve real impact.

• Possible Use of AI/LLM Code Generation:
  Code patterns suggested assistance from large language models, indicating hurried or inexperienced authorship.

3. Gap Between Intent & Capability ([08:31]–[11:16])

• Intent: Specific targeting of known Israeli utilities and water plants suggests deliberate design.
• Execution: Incomplete functionality and critical coding error meant the malware was essentially harmless.
  • Schwabi: “It actually has no functionality built in to, for example, touch a PLC… It would still rely on human interaction... so unlikely to get that far that the execution really falls short...” ([09:31])

4. Speculation: Prototype, Mistake, or Psyop? ([12:50]–[15:05])

• Prototype/Testing Version?
  The flaws suggest early development, possibly an internal testing artifact accidentally published.
• False Flag/Psyop Possibility:
  The overt targeting and non-functionality raise the possibility of psychological operations—either to misattribute blame or to inflate perceived threats.
  • Schwabi: “...there's also a slight possibility that this may have been some kind of psyop false flag operation...” ([12:50])

5. Attribution & Analytical Restraint ([13:55]–[15:05])

• Schwabi’s Caution:
  Attribution is inherently challenging. Domain Tools avoids speculation and only presents evidence, never making definitive statements without irrefutable proof.
  • “Unless you were there in the room where it happened, it is all speculation...” ([14:15])

6. Why Defenders Should Care: OT Remains a High-Value Target ([15:19]–[18:40])

• Industrial Control System Vulnerability:
  Many SCADA environments, initially designed for isolation, became Internet-connected in the 2000s—without security as a priority. This legacy continues to leave critical infrastructure exposed.
  • “Back in the day, those things … were never really … intended to be connected to the Internet. Then … vendors … started crafting systems that allowed these existing control systems that only spoke serial to be connected to a box that then was connected to the Internet.” ([15:19])
• Potential for Societal Disruption:
  Utility attacks (water, sewer, electricity) can have immediate public impact and undermine trust in government.

7. Lessons and Recommendations for Defenders ([18:40]–[20:54])

• Least Privilege:
  Minimize admin rights. Malware requiring privilege escalation should trigger IT/security review.
• User Education:
  Teach users to be wary of suspicious file names—especially those that are generic or incongruent with vendor norm.
• Endpoint Protections:
  Use antivirus/EDR to catch attempts at unauthorized persistence or privilege escalation.
  • “Training is really the best thing you can do there. But also locking down the local system used to those things have endpoint protection on there, whether it's EDR or even just antivirus …” ([19:30])

8. Actor Sophistication—Real or Simulated? ([20:54]–[23:23])

• Possibly Low-Skilled, Possibly Deceptive:
  The code appears amateurish, perhaps the product of LLM code assist and haste. Alternatively, the flaws might themselves be a form of misdirection.
  • “It does feel like it was LLM assisted coding, which even for legit purposes we run into, where maybe some more junior developers… will rely on LLM code assist, which can be very powerful, but you still have to understand what the output … is.” ([21:17])
  • “If it was the other potential... false flag operation, then … it would have been more effective if it … at least attempted to do some damage…” ([22:45])

---

Notable Quotes & Memorable Moments

• On the malware's effectiveness:
  “It actually has no functionality built in to, for example, touch a PLC … so unlikely to get that far that the execution really falls short…” – Daniel Schwabi ([09:31])

• On the importance of attribution discipline:
  “Unless you were there in the room where it happened, it is all speculation... we will never specifically attribute something to a particular threat actor just because it's impossible to know.” – Daniel Schwabi ([14:15])

• On the risk landscape:
  “Industrial control systems and their operational technology remain a very interesting and big target for adversaries because they're typically tied to things like municipal water systems… It can create distrust in government by the population real fast, which is why it's a very interesting targeting tool...” – Daniel Schwabi ([17:06])

• On user education:
  “...getting more specific with user education that something like the particular file name that was used here, again, is too on the nose. Is this really what you're expecting? ... That’s kind of a user education problem.” – Daniel Schwabi ([19:34])

---

Timestamps for Important Segments

• [01:25] – Initial discovery and discussion of suspicious file name
• [04:37] – Evidence of targeting Israeli water infrastructure
• [06:20] – Technical flaw in geographic targeting logic
• [07:12] – Confirmation of non-functionality in intended target environment
• [08:31] – Discussion of intent vs. capability
• [12:50] – Speculation on prototype/psyop vs. real threat
• [14:15] – Caution in attribution
• [15:19] – Risks and history of OT/SCADA network exposure
• [18:40] – Recommendations for defenders
• [21:17] – Assessment of actor sophistication and possibility of deliberate amateurism

---

Key Takeaways

• Zion Siphon is a malware sample with a “bark” (threatening intent) but no real “bite” (capability to achieve its suspected goals).
• Its public discovery is a reminder of both the challenges of malware attribution and the necessity for robust, multi-layered OT security.
• Defenders must focus on least privilege, vigilant user education, and up-to-date endpoint protections for critical infrastructure.
• “More bark than byte” threats can still influence perception or serve as trial balloons for future, more refined attacks.

---

For detailed research, see Domain Tools’ full report ("Zion Siphon OT Malware: First Attempts, Psyops, Both").

Transcript

[A]

You're listening to the Cyberwire Network, powered by N2K.

[B]

AI is making phishing attacks faster, more convincing, and harder for people to spot. And traditional security awareness and phishing training weren't designed for this level of attack. HOX Hunt helps security teams prepare employees for the attacks they face every day with personalized phishing training that adapts to each employee and reduces risky behavior over time for IT and security leaders looking to strengthen their human layer of defense without adding more manual work. Visit hoxhunt.com cyberwire to learn more. That's H O X h u n t.com cyberwire. Hello everyone, and welcome to the Cyberwire Research Saturday. I'm Dave Bittner and this is our weekly conversation with researchers and analysts tracking down the threats and vulnerabilities, solving some of the hard problems, and protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us.

[A]

We've been focusing on various threat actors in the Middle east and this came across our desk, I would say, just because it was allegedly focusing on Israel based on the metadata that we were able to see in the malware. And so we decided to look into it a little bit more in depth and see if any conclusions that we could draw.

[B]

That's Daniel Schwabi, chief Information Security officer and head of investigations at Domain Tools. The research we're discussing today is titled Zion Siphon OT Malware First Attempts Psyops Both. But when you first encountered this malware sample, what was it that made you think that maybe it needed a closer look than, say, ordinary Windows malware?

[A]

Yeah. So I would say the fact that the naming itself was kind of a little bit too on the nose, and then the other results that our colleagues had already published on some of the functionality got my attention. And I was thinking, what's the actual purpose of this thing? Because as we're going to, I'm sure talk about it's not very effective the way it was designed. So my question was, is this a junior attempt and didn't get seen through? How did it actually get out in the public? Was it leaked? Was it an accident? Was somebody trying to test whether malware scanners would pick it up and not realizing that sandbox providers share the stuff and it goes wide, or is it actually more of a psyop attempt to portray capability without an actual intent to actually push that stuff out there? That was kind of my hypothesis and I said we should look at this because there might be some interesting conclusions we could draw.

[B]

Well, you mentioned the name. The file name was named Scada security patch version 8.4 exe, as you say, that is a bit on the nose. Unusual for something to be so overt.

[A]

Yeah. And I've, at one point in my career I was responsible for securing SCADA and industrial control systems on a very large network. And why I personally would not handle the patching, we would certainly work with the engineers that did. And I've never come across any executable named something like that. It's typically more, you know, towards the manufacturer. Like Siemens is a big one and they have a naming convention. This is not something I've ever come across. And that kind of caught my attention because having no product name in it and calling it just Security Patch and then some arbitrary version after that stood out to me.

[B]

Well, let's go down the pathway here of following some of these clues. As you all began reverse engineering this malware, there was evidence suggesting it was focused on water infrastructure.

[A]

Correct. There are some hints in the malware that seem to target specific facilities. Water, water treatment facilities within Israel. They're named by name, so it felt like that was the intended target. You know, of course, it's impossible to say what the real intent here was, but based on circumstances and hints in the malware itself, et cetera, that seems like a likely target.

[B]

So for folks in our audience who don't work in industrial control systems, can you explain why things like chlorine dosing, reverse osmosis systems, why are these significant components of water operations?

[A]

Yeah, so in general, water treatment, of course, takes dirty or polluted water or wastewater and tries to turn that back into potable drinking water. And there's various different ways of doing that. US based water treatment has slightly different techniques of doing that, but basically you remove the solids from it, you try to filter out as much of the other matter, but then the water that's left might still have bacteria or other bad things in it. And chlorine is one commonly accepted way to kill the bad things in the water, and the chlorine will eventually evaporate and not stick around, and so it becomes safe again for humans to consume.

[B]

So you started to dig into the malware's activation logic, and that's where things kind of take a turn here. What exactly did you find?

[A]

Yeah, so the biggest one, without bearing the lead here, is that basically it has a faulty location identification logic. Basically, the malware was intended to say, Mr. Checking its environment, checking its IP address or whatever. Am I in Israel? Am I being run on a system that's connected to Israeli IP space, which is knowable. And if that's the case, execute. If it detects that it's anywhere else, like in the surrounding area in the Middle east, or really anywhere around the world, if it's not connected to Israeli IP space, then it just kills itself. There's a flaw in that logic where the Am I in Israel part will never be true. It's an XOR bug, and basically it never has a chance to run in the version in the form that was uploaded to the sandboxes that we were able to analyze.

[B]

So to be clear here, does this mean that this may have never successfully executed in its intended geographic region?

[A]

This is what we believe, that particular version. That's not to say that other versions couldn't have been developed afterwards, that maybe didn't get caught publicly, but this particular version that we looked at had no chance to ever working.

[B]

How unusual is it to find a fundamental flaw like this in a malware sample?

[A]

It's not unusual, but this feels like maybe an early version that was like in testing and somehow this didn't get caught yet, or it was intentionally set so you couldn't accidentally detonate it during the testing phase. But it's. It's kind of a big miss to release something like that or let it get out into the public sphere with such a critical error. Looking at the structure and stuff of the malware itself, it has indications that maybe Vibe coding and LLM Assist was being used, which that kind of tells me that maybe whoever did it was either in a real big hurry or was more junior and wasn't fully thinking through what all of the functionality would need to hit.

[B]

One of the really interesting themes in your report is what you all describe as a gap between intent and capability. Can you describe that gap for us?

[A]

This particular malware seems to have been designed to target these specific water treatment facilities in Israel. Like in the code, they are named like Mekorot, Sorec. There's a whole bunch of them that are named by name in there. That's also kind of interesting, and it almost seems like that was meant to be discovered. So that's interesting. That's not to say that other malware that was successful wouldn't do something similar, but to be so explicit here is an interesting tell. And then the fact that it had the rudimentary capability of installing itself on a system and running, but a the validation error of the location basically made it so it could never execute. But additionally, it doesn't really have components in there to actually, let's say location validation test. Let's say it passed. Oh, I'm on an Israeli ip, I'm going to execute myself. It actually has no functionality built in to, for example touch a pcl. So programmable logic controller, a little piece of firmware that can affect things on an industrial control system. Stuxnet, which this is often compared to, is not even in the same universe. It's way more sophisticated and it's targeting the industrial controllers directly. Where this particular malware basically relies on a Windows host to execute and then would try to write some configuration files to a controller like a PCL that might be connected to this Windows host, but there is no mechanism to actually push it there. So it would still rely on human interaction to then take the malicious files and copy them to a system that might want to be compromised that is so unlikely to get that far that the execution really falls short of what its likely potential intent was.

[B]

We'll be right back. When it comes to mobile application security, good enough is a risk. A recent Survey shows that 72% of organizations reported at least one mobile application security incident last year and 92% of responders reported threat levels have increased in the past two years. Guard Square delivers the highest level of security for your mobile apps without compromising performance, time to market or user experience. Discover how Guard Square provides industry leading security for your Android and iOS apps at www.guardsquare.com. Most environments trust far more than they should, and attackers know it. ThreatLocker solves that by enforcing default deny at the point of execution. With ThreatLocker allowlisting, you stop unknown executables cold. With ring fencing you control how trusted applications behave. And with threatlocker DAC defense against configurations, you get real assurance that your environment is free of misconfigurations and clear visibility into whether you meet compliance standards. ThreatLocker is the simplest way to enforce zero trust principles without the operational pain. Its powerful protection that gives CISOs real visibility, real control and real peace of mind. ThreatLocker makes zero trust attainable even for small security teams. See why thousands of organizations choose ThreatLocker to minimize alert fatigue, stop ransomware at the source, and regain control over their environments. Schedule your [e-mail] N2K today. Well, the report raises the possibility that this malware could be a prototype.

[A]

Yes, it does feel like that. So there's just several different, you know, it's all speculation. I mean we of course we use our expertise and other things that we have seen to kind of speculate here. But I want to be very clear there is no, you know, very clear smoking gun here. It feels like it possibly was an early development version that got accidentally released, wasn't meant to get out yet, and additional functionality was supposed to be baked in. There's also a slight possibility that this may have been some kind of psyop false flag operation. You know, trying to frame certain entities that might want to harm Israel, but make it so that it couldn't actually actively harm something and just put the allegation out there that maybe an Iranian actor or somebody sympathetic to their cause may have been behind that, but it might really have been counter psyop operation where entities that are friendly to Israel put this out to frame their adversaries. We don't know that, but it's a possibility.

[B]

Right? Can you give us a little view behind the scenes? I mean, how do you and your colleagues avoid jumping to conclusions? In this case, the malware seems to be pointing directly at a particular country or particular threat actor. How do you resist that temptation experience?

[A]

I would say because attribution is really, really hard even for the best of us. And there are, let's be fair, there are people out there in our industry who run circles around us like we're pretty good at this, but we are by no means the top experts on this. And so as the lead of our research team, I read all articles before they go out and I do a risk review and I make very sure that we do not make strong attribution claims because ultimately, unless you were there in the room where it happened, it is all speculation to the best of it. So one of our internal doctrines is like, we will lay out the evidence that we can find and we might put some hypotheses out there, but we will never specifically attribute something to a particular threat actor just because it's impossible to know.

[B]

Well, given that Zion Siphon is not indeed fully operational, it doesn't work as a cyber physical weapon. Why should defenders be paying attention to this? What makes this important?

[A]

The targeting, at least a conceptual way could be successful. And it's not a big secret that industrial control systems SCADA has some issues and can be vulnerable. And there was a time in, I would say the early 2000s where basically worldwide, any SCADA, which by the way, that stands for Supervisory Control and Data Acquisition, that's a common acronym used in that industrial control circles. And back in the day, those things like a valve to turn on a water or a sewer pump, et cetera, how fast or how slow it goes, etcetera, Those would all be controlled over serial Bus or some proprietary protocols. They were never really, in the early days, intended to be connected to the Internet. Then with the advent of let's put everything online of the early to mid 2000s, vendors and third parties started crafting systems that allowed these existing control systems that only spoke serial to be connected to a box that then was connected to the Internet. But security at the time was not really top of mind. It was meant to be, oh, this will make it so much easier. We can control everything from one single point rather than having to aggregate all of the serial connections somewhere few people would still have to go on site, etc. It was meant to make things easier and more efficient. But in the early days, security was not top of mind. And so threat actors pretty quickly figured out that they were easily compromisable and they could cause havoc with that.

[B]

What do you suppose this malware tells us about where these OT threats might be headed? Are there any forward facing lessons to be learned here?

[A]

I do think industrial control systems and their operational technology remain a very interesting and big target for adversaries because they're typically tied to things like municipal water systems. There's industrial controls, obviously in nuclear power plants and industrial manufacturing, et cetera, but where it affects the general public the most is water, sewer, energy, natural gas, et cetera, they're all hooked to these control systems. If as an adversary I can target those and either cause them to go down, fail catastrophically, or cause some other issue that will be felt by the population, which will then come to their government, be like, hey, what the heck is going on? And it creates a very big public impact. If you manage to stop the sewer pumps in Seattle, we have a bunch of big hills and stuff needs to get pumped from one elevation to the other. If you manage to shut those off, or worse, break them by trying to run them in reverse back and forth real quick, that will take a long time to fix, and in the meantime, people still need to use the bathroom. Where is that stuff going to go? It can create distrust in government by the population real fast, which is why it's a very interesting targeting tool to create up to civil unrest in the worst case.

[B]

Yeah, well, based on the information you've gathered here, what are your recommendations for the defenders out there? What should they be doing based on your research?

[A]

It kind of comes down to like, stuff that we've been talking about forever. You ideally don't have admin privileges on the workstation you run. Now, this particular malware, initially, if somebody had got it onto their system and Double clicked the. Exe file, it would have installed itself with persistence, with user level permissions. So that's hard to prevent. But a bunch of other stuff copying itself into certain locations that are protected by the system by default would require a privilege escalation where basically in Windows a little box pops up and tells the user, hey, do you really want to do this? Yes. No. Most people are so trained to just click yes and not pay attention, so that likely would have been successful. But if it's a situation where a particular user does not have local admin rights, it would prompt for a username and password of a account that has these admin rights. In some situations, the users are given that, so they can still log in with a separate account to authorize that. Or in other situations they have to talk to their IT support team and like, hey, I need admin privileges to install this. And then it's an opportunity for the IT or the support team or the security to be like, hey, what a sec, wait a second, what are you doing here? So that's one thing. The other thing is getting more specific with user education that something like the particular file name that was used here, again, is too on the nose. Is this really what you're expecting? If you've done this before, Is this the type of file name that you would reasonably expect from a vendor? So that's kind of a user education problem. So it really comes down as overcoming the social engineering aspect, which gets quite good. And so training is really the best thing you can do there. But also locking down the local system used to those things have endpoint protection on there, whether it's EDR or even just antivirus programs that might look at the executable you're about to detonate on the system and says, wait, that's going to do some bad things. We're going to stop it. So basically have antivirus anti malware on the system operate with the least amount of privileges as possible and user education, so they don't just blindly try to execute any.exe file that comes across their desk.

[B]

You know, Daniel, I routinely ask folks to rate the sophistication of the malware actor, but in this case it's possible that they were unsophisticated, but it's also possible that they were trying to signal being unsophisticated as misdirection. How do you unpack that?

[A]

Yeah, that's an excellent question. So independent of who might have been behind it, the executable that reached the sandbox, which we are looked at I would consider flawed and not very well thought out. Now that may be the point in time at this particular executable was compiled and there may have been plans to make it more effective in later versions, but we only came across this particular version, so that's all we have to go on. It does feel like it was LLM assisted coding, which even for legit purposes we run into, where maybe some more junior developers who receive pressure to write code faster will rely on LLM code assist, which can be very powerful, but you still have to understand what the output of that is. Internally we have a rule that says yes, you may use certain LLM code assist things, but the code that it produces will be judged as if you wrote it. So you can't say, oh well, I used Copilot and it just made the mistakes. Not my fault. No, if you use that, you're expected to fully understand the code and know what it does so it can make you faster, but you can't absolve yourself from the responsibility of understanding what actually happens. In this particular case, it does seem like it was a rush job that might not have been very well thought out and then an early version got out and this is what we're looking at now. If it was the other potential where it was meant as a false flag operation, then in my opinion it would have been more effective if it, you know, at least attempted to do some damage and then would have been stopped by normal means rather than, you know, not even able to execute ever because of the fault in the location identification logic.

[B]

Our thanks to Daniel Schwabi, Channel Chief Information Security Officer at Domain Tools, for joining us. The research is titled Zion Siphon OT Malware First Attempts Psyops Both. We'll have a link in the show notes and that's Research Saturday brought to you by N2K CyberWire. We'd love to know what you think of this podcast. Your feedback ensures we deliver the insights that keep you a step ahead in the rapidly changing world of cybersecurity. It if you like our show, please share a rating and review in your favorite podcast app. Please also fill out the survey in the show notes or send an email to cyberwire2k.com this episode was produced by Liz Stokes. We're mixed by Elliot Peltzman and Trey Hester. Our executive producer is Jennifer Ibin. Peter Kilpe is our publisher and I'm Dave Bittner. Thanks for listening. We'll see you back here next time.

[A]

This episode is brought to you by Google Chrome. You think you know a browser. But Gemini and Chrome? That's new. It can help you with practically anything on the web, like restoring a vintage motorcycle from a 50 page restoration block. Or finally break down that long article you've had open for weeks. Gemini and Chrome is here for it, ready to make anything online make sense. There's no place like Chrome. Check responses set up required compatibility and availability various 18.