CyberWire Daily - More bark than byte. [Research Saturday]

Episode Date: June 27, 2026

This week we are joined by Daniel Schwalbe, Chief Information Security Officer & Head of Investigations at DomainTools, discussing their work on "ZionSiphon OT Malware First Attempts? Psyops? Both?" Researchers at DomainTools take a closer look at ZionSiphon, a purported operational technology malware sample targeting the water sector, and find that despite its alarming appearance, it lacks many of the capabilities needed to function as a credible cyber-physical weapon. They break down the malware's architecture, its operational shortcomings, and why it may be more of a prototype or proof of concept than a deployable threat. With heightened concern surrounding attacks on critical infrastructure amid the ongoing U.S.-Iran conflict, the research offers timely insight into separating genuine OT threats from overhyped malware. The research and executive brief can be found here: Threat Intelligence Report: ZionSiphon OT Malware First Attempts? Psyops? Both? Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyberwire Network, powered by N2K. AI is making fishing attacks faster, more convincing, and harder for people to spot, and traditional security awareness and fishing training weren't designed for this level of attack. Hawkshunt helps security teams prepare employees for the attacks they face every day, with personalized fishing 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 slash cyberwire to learn more. That's h-o-x-h-U-N-T.com slash cyberwire. Hello, everyone, and welcome to the Cyberwires 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, the hard problems and protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. 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 any conclusions that we could draw.

That's Daniel Schwabby, Chief Information Security Officer and Head of Investigations at Domain Tools. The research we're discussing today is titled Zion-Syphon OT malware, first attempts, sci-ops, 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? Yeah, so I would say the fact that it was, 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 sci-op attempt to portray capability without an actual intent to actually push that stuff out there.

That was kind of my hypotheses, and I said we should look at this because there might be some interesting conclusions we could draw. Well, you mentioned the name, the file name was named Skata Security Patch version 8.4.exe. As you say, that is a bit on the nose. Unusual for something to be so overt?

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 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 a security patch and then some arbitrary version after that that stood out to me. 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? Correct. There are some hints in the malware that seem to target specific things. facilities, water treatment facilities within Israel.

They're named by name. So it felt like that was the intended target. 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. So for folks in our audience who don't work in industrial control system, Can you explain why things like chlorine dosing, reverse osmosis systems, why are these significant components of water operations?

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. 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? 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,

am 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 MI and 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. So to be clear here, does this mean that this may have never successfully executed in its intended geographic region? 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. How unusual is it to find a fundamental flaw like this in a malware sample? It's not unusual, but this feels like maybe an early version that was in testing and somehow this didn't get caught yet. Or it was intentionally set, so you couldn't accidentally detonated during the testing phase. But 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. 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? This particular malware seems to have been designed to target these specific water treatment facilities in Israel. Like in the code, there are, they are named. Like, McCorot, Sorek, 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 the 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 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 a programmological 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. 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.gardsquare.com. Most environments trust far more than they should, and attackers know it. Threat Locker solves that by enforcing default deny at the point of execution. With Threat Locker Allow listing, you stop unknown executables cold. With ring fencing, you control how trusted applications behave. And with Threat Locker, DAC, defense against configurations, you get real assurance that your environment is free of misconfigurations

and clear visibility into whether you meet compliance standards. Threat Locker is the simplest way to enforce zero-trust principles without the operational pain. It's powerful protection that gives CISO's real visibility, real control and real peace of mind. Threat Locker make zero trust attainable, even for small security teams. See why thousands of organizations choose Threat Locker to minimize alert fatigue, stop ransomware at the source, and regain control over their environments. Schedule your demo at Threatlocker.com slash N2K today.

Well, the report raises the possibility that this malware could be a prototype. 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 SIOP false flag operation 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-Syop 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. 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, you know, the malware seems to be pointing directly at a particular country or a particular threat actor. How do you resist that temptation?

experience, I would say, because attribution is really, really hard, even for the best of us. And there are, that'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're by no means, you know, the top experts on this. And so as the lead of our research team, you know, 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. Well, given that Zion Seifan is not indeed fully operational, it doesn't work as a cyberphysical weapon, why should defenders be paying attention to this?

What makes this important? 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 is, where that stands for supervisory control and data acquisition. It'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, et cetera, 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, you know, let's put everything online. of the early to mid-2000s, vendors and third-party 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. People would still have to go on site, et cetera. 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. 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? 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 like nuclear power plants and industrial manufacturing, et cetera, but where it affects the general public the most is water, sewer, you know, energy, natural gas, etc. 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 like 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. 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? it kind of comes down to like stuff that we've been talking about forever, forever. You ideally don't have admin privileges on the workstation to your run. Now, this particular malware initially, if somebody had got it under their system and double-click the EXC file, it would have installed itself with persistence with user-level permission. 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 giving 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 Averman 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 second? Wait a second. What are you doing here? So that's one thing.

The other thing is getting more specific with user education that, you know, something like the particular file name that was used here, again, is two 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 and our 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 XZ file

that comes across their desk. 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? Yeah, that's an excellent question. So, independent of who might have been behind it,

the executable that reached the sandbox, which we 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 there 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 at least attempted to do some damage and then would have been stopped by normal means rather than not even able to execute ever because of the fault in the location identification logic. Our thanks to Daniel Schwabby, Chief Information Security Officer at Domain Tools for joining us. The research is titled

Zion Siphon OT malware first attempts, Psiops, 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. 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 Cyberwire at N2K.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. Are you one of those media strategy people clicking through slides, scrolling spreadsheets? Yes? Good. This is for you.

Because on Spotify, there's an audience that's different. Locked in. Loyal, invested. They're called fans. Fans don't just listen to music. They feel seen by it like it belongs to them. So when your brand shows up on Spotify, that's who you're talking to. And you're right next to artists like me, Lizzo. So, are you ready to talk to fans?

Spotify advertising. You're among fans.