More bark than byte.

Dave Bittner: Hello, everyone and welcome to the CyberWire's "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. [ Music ]

Daniel Schwalbe: 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 could draw.

Dave Bittner: That's Daniel Schwalbe, Chief Information Security Officer and Head of Investigations at DomainTools. The research we're discussing today is titled "ZionSiphon OT Malware First Attempts? Psyops? Both?" [ Music ] 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?

Daniel Schwalbe: 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? Is it, was it leaked? Was it an accident? Was somebody trying to test whether the malware scanners would pick it up and not realizing that Sandbox provider shared this stuff and like it was wide? Or, is 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 hypotheses and I said we should look at this because there might be some-some interesting conclusions we could draw.

Dave Bittner: Well, you mentioned the name, the file name was named SCADA security patch version-version 8.4.exe as you say. That has been on-the-nose; unusual for something to be so overt?

Daniel Schwalbe: Yeah. And I have, at one point in my career I was responsible for securing SCADA industrial controls, but since I'm a very large network and why I personally would not handle the patching, we would certainly work with engineers that did and I've never come across any executable named something like that. It's typically more, you know, to a 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 naming it and calling it just a security patch and then some arbitrary version after it that-that stood out to me.

Dave Bittner: Well, and let's go down the pathway here of following some of these clues is, as you all began reverse engineering this malware, there was evidence suggesting it was focused on water infrastructure?

Daniel Schwalbe: Correct. There are some hints in the malware that seemed to target specific facilities, 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 the hints in the malware itself, et cetera, that seems like a likely target.

Dave Bittner: 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, the-why are these significant components of water operations?

Daniel Schwalbe: Yeah. So, in general, water treatment of course takes dirty, or polluted water, or waste water and tries to turn that back into potable drinking water and there's various different ways of doing that. U.S.-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.

Dave Bittner: 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?

Daniel Schwalbe: Yeah. So, the biggest one without, you know, burying 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 is a flaw in that logic where the "Am I in Israel" part will never be true, [inaudible 00:06:06] or 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.

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

Daniel Schwalbe: 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 publically, but this particular version that we looked at had no chance to ever working.

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

Daniel Schwalbe: It's not unusual, but this feels like maybe an early version of that was like in testing and somehow this didn't get caught yet, or it was intentionally set so you couldn't accidently detonate it 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. It-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.

Dave Bittner: You know, one of the really interesting themes in your report is what you all describe as a gap between intent and capability.

Daniel Schwalbe: Yeah.

Dave Bittner: Can you describe that gap for us?

Daniel Schwalbe: This particular malware seems to have been designed to target these specific larger drink facilities in Israel. Like in the code, there are names like, Mekorot, 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-that's interesting. That's not to say that other malware that were 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 had 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 tests, 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. Its way more sophisticated and it's targeting the industrial controls 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-is so unlikely to get that far that the execution really falls short of what its likely potential intent was. [ Music ]

Dave Bittner: We'll be right back. [ Music ] Well, the report raises the possibility that this malware could be a prototype.

Daniel Schwalbe: Yes. It does feel like that. So, there's just several, you know, different, you know, it's all speculation. I mean, 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 advisories. We don't know that, but it's a possibility.

Dave Bittner: 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?

Daniel Schwalbe: Experience 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, 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 layout 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.

Dave Bittner: Well, given the ZionSiphon 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?

Daniel Schwalbe: The targeting, at least the conceptual way, could be successful. And it's not a big secret that industrial control systems SCADA, is-has some issues and can be vulnerable. And the-there was a time in, I would say, the early 2000s where basically worldwide any SCADA, which by the way that stands for supervising control and data acquisition. It's a common acronym used in that industrial control circles. And back in the day those things like, you know, a valve to turn on water or, you know, 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 mid2000s, 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; [inaudible 00:13:52] people would still have to go onsite 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.

Dave Bittner: 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?

Daniel Schwalbe: 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, you know, this-industrial controls obviously in like nuclear power plants and industrial manufacturing, etcetera, but where it affects the general public the most is water, sewer, you know, energy, natural gas, et cetera and 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, you know, stop the sewer pumps in Seattle, have a bunch of big hills and stuff needs to get pumped from one elevation to the other. If you managed 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 longtime 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.

Dave Bittner: 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?

Daniel Schwalbe: 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 onto the system and double-clicked the exe 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, 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-given that so they can still login 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 team to be like, "Hey, 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 too on-the-nose; is this really what you were 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, you know, have endpoint protection on there, whether it's you know EDR or you know 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 antimalware on the system, operate with the least amount of privileges as possible and user education so they don't just blindly, you know, try to execute any exe file that comes across their desk.

Dave Bittner: You know, Daniel, I routinely ask folks to rate the sophistication of the malware actor, but you know 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?

Daniel Schwalbe: Yeah. That's an excellent question. So, independent of who might have been behind it, the executable that reached the Sandbox which we all 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 you know, 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 in for legit purposes, we run into where maybe some more junior developers who receive pressure to like, you know, write code faster will rely on LLM code-assist which can't be very powerful, but you still have to understand what the output of that is. We have 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 you know Copilot and it just made the mistake. It's 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-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 launch. [ Music ]

Dave Bittner: Our thanks to Daniel Schwalbe, Chief Information Security Officer at DomainTools for joining us. The research is titled "ZionSiphon 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 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@n2k.com. This episode was produced by Liz Stokes, we're mixed by Elliott Peltzman and Tre Hester. Our executive producer is Jennifer Eiben. Peter Kilpe is our publisher and I'm Dave Bittner. Thanks for listening. We'll see you back here next time. [ Music ]