Ric Derbyshire on Living-Off-the-Plant OT Cyberattacks

Ric Derbyshire, a Principal Security Researcher at Orange Cyberdefense and an Honorary Researcher at Imperial College London, joins the Nexus Podcast to discuss how attackers are able to gain lateral movement across operational technology (OT) assets through a tactic known as Living Off the Plant.

Similar to Living-off-the-Land attacks, Living-Off-the-Plant TTPs leverage native functionality specific to OT, with a potential negative impact on physical assets and safety concerns. 

Subscribe and listen to the Nexus Podcast here. 

Transcript

SPEAKER_01 0:00

If you can just give me the hello whatever side button. Perfect.

SPEAKER_00 0:05

Are we holding these as well? Yes. Okay. Yeah, this is just for Joel's side. Cool, and then probably.

SPEAKER_01 0:11

And you can hold it fairly close to us. It'll sound even better. Alright, Joel, you ready? Alright. Drag this down so I can see. Okay. Alright, welcome back to the Nexus podcast. Rick Darbisher of Orange Cyber Defense is my guest. And we're going to talk about some research that was published recently that explores how an attacker might move laterally within operational technology environments. We've got a brand new catchphrase in Cyber, living off the plant. That's a new one to me anyway. So welcome.

SPEAKER_00 0:44

Thank you very much. Thanks for having me, Mike.

SPEAKER_01 0:46

Yeah. Tell me a little bit about your background or career path. I think that's always interesting for people to kind of hear.

SPEAKER_00 0:51

I've had one of those like weirdly generic but also kind of strange career paths. I um did the whole like computer science at university and did penetration testing for a few years, but then went back and did a PhD in the most riveting topic of quantitative cyber risk assessment. But the university I was researching at also had a strong OT presence, and I kind of fell into it accidentally. And from there it's kind of just been OT all the way. So I worked for a systems integrator for a year or so, and then I ended up in our own cyber defense because it was a research-specific job, and uh once you get into research, it's kind of addictive, and you have to find stuff.

SPEAKER_01 1:35

Um yeah, because it it's funny, like there's no kind of direct career path to OT cybersecurity.

SPEAKER_00 1:42

No, it's tragic, it's really difficult, and it requires a lot of investment, which is why working at a university that had a big test bed, um, it was a very fortunate position. So I probably grabbed that when I could. Yeah. That's great.

SPEAKER_01 1:56

Um so as I was looking at some of the materials sent me uh to help me prepare for this, it just didn't seem that there's a lot of either discussion or available research on lateral movement within OT environments. So is that kind of the motivation for you? Did you see a gap there or was it something else?

SPEAKER_00 2:13

This no, it was actually accidental. In fact, um we actually stumbled across this as a way to try and propagate a ransomware technique. And as we were doing that, we realized that we could be much more targeted and specific with how we were using it, and then we realized that we could basically um proxy everything through it, so so we could basically use um certain library functions in one PLC to talk to another PLC, and we could abuse reads and writes and all sorts of things through doing that. So we kind of accidentally stumbled across it and then just rolled with it. But there has been some some other work, so um um there's a researcher in the Netherlands called Jos Vetsels who's um who basically did a really like comprehensive look at it a few years ago. Um and yeah, this this doesn't really um contradict it or anything, it kind of complements it quite well. So it's interesting.

SPEAKER_01 3:15

So I I think traditional lateral movement is sort of understood between IT assets, yeah, or maybe even between IT and OT. I don't know. How much more difficult is it to get into you know, through the DMZ on the Purdue model, into you know the field assets, which is what your your research is about, just kind of moving between those field assets.

SPEAKER_00 3:36

So wait, as in so we we don't I don't know how to do it. I like a compare or contrast, I guess. Oh right, okay. So it's really difficult purely because when you're doing lateral movement between, say, for example, two IT assets, you're basically going from one more or less remote code execution to another remote code execution. Whereas that kind of that kind of TTP isn't something that you typically find or do that frequently in in OT. You're not you're not using remote code execution that frequently on programmable logic controllers, for example. So instead we're having to use the actual native functionality that is just there on the PLCs as part of its its its general day-to-day life, essentially. Sure. So it's not quite as persistent. Maybe it would be um appropriate to to say it's kind of like hybrid proxy/slash lateral movement because it's not quite as um it's not quite as permanent, but still it's it it does laterally move. You can do all of the functionality you need through it.

SPEAKER_01 4:39

Because more understood attacks against PLCs are like manipulating upload and download data, is that fair to say?

SPEAKER_00 4:44

Or yeah. Um yeah, like so for example, Stuxnet is is manipulating data downloaded to the PLCs. Um but this is much more utilizing, for example, uh I mean, this is semen-specific, so it's abusing the S7COM protocol. Right. And it's abusing library functions, specific library functions that are typically used to communicate between PLCs. So we're basically just piggybacking on those library functions.

SPEAKER_01 5:09

And so uh moving between OT assets that way is it what are the barriers? Why is it so difficult? Or is it just it hasn't been explored very much?

SPEAKER_00 5:21

I don't know. I think um one of the reasons that I guess it hasn't been explored is because uh it's not really necessarily being seen as necessary. Um typically you you kind of assume that network segregation is the the main defense in operational technology. It's like the kind of like the the the final, it's like perimeterizing everything. Um so we we just assume that network segregation is gonna work and that's gonna be fine. So if the adversary can only get access to one PLC and it can't get access to um to more, then they can't do anything about it. Um but I don't I don't know. Um I I I I guess maybe because it's more like I say, using this living off the plant kind of approach, that's just native functionality, which doesn't seem to be that prevalent in current research. A lot of the research is still quite cyber focused, so it's maybe not so much focused on the OT infrastructure OT like functionality itself. Um it's a hard one. I have no idea.

SPEAKER_01 6:25

Um obviously living off the land attacks got a lot of attention with the typhoons and the activity of of that group uh on critical infrastructure. Um is the the main advantage of using that type of technique is it just because it's it just blends in, it looks like normal traffic, it doesn't look malicious, or is there are there other more subtle advantages to it?

SPEAKER_00 6:47

So that's one of the main advantages, and that's where it kind of um it mirrors a lot of like the typical living off-the-land advantages that you'd see in IT. But one thing that we noticed when we were collecting a data set of publicly reported cyber attacks that had uh had cyber physical impact um was that there were this small set of impacts that we saw that were unique to uh attacks that had included the use of OT tactics, techniques, and procedures. And the majority of those tactics, techniques, and procedures that are uh specific to OT are native functionality. And what we saw were those were the impacts that we were really scared of. Things like manipulation of control, loss of uh protection, damage to property, loss of safety. These are the kind of things that we actually talk about and we worry about when we talk about cyber physical impacts. So when we separate those out and we say, hey, these are the ones that we're actually seeing. Um it kind of makes sense to start pursuing this as a research path and say, can we actually see is it are the patterns there? Or I mean, unfortunately, my most of my kind of research is troublemaking, so kind of making it worse, I guess. But uh at the same time, we've had really good vendor responses when we've like kind of published this, and um so I'm hoping we're making the world a better place in some way or not.

SPEAKER_01 8:07

Yeah, um, I mean you're right though, it this is largely unexplored territory. I mean, there's only a dozen malware samples that have really been written specifically for OT. Even on the attacker side, this is kind of like still niche, right? Yeah. Um so with with PLCs, is there's still a certain air about them that they're kind of untouchable, that they're s I I don't want to say kind of walled off, but I don't know whether they're untargeable.

SPEAKER_00 8:38

Yeah, so we assume that they're air gap, but also we assume that they're kind of assumed to be actually extremely vulnerable, but at the same time vulnerable in a very specific way, I guess. Um one of the one of the things I try and preach is that just having access to the OT doesn't mean that it's game over. In order to actually be able to make a PLC do something that's actually useful for an attack narrative, unless you just want to have that PLC break and turn off, which by all means is a very viable impact to cause. But if you want to do something stealthy and persistent over time, so it's actually doing something very specific, then you need to know more about the environment that you find yourself in as well. So um one of the other things that I've been trying to, I guess, preach is this this idea of process comprehension and understanding um the need for an adversary to understand the physical environment that they find themselves in, and also how the OT basically controls, automates, and monitors that physical environment, how the cybersecurity controls and network architecture are in place, the people and then the the physical security and the safety features are all how it all works together in that specific victim environment. And then once you know that you can start to actually construct an actual really meaningful and specific attack. Um and I think that's kind of lost on many cases when we kind of just say, oh well, once you get there, it's it's game over, it's really easy. Because that kind of then just dumbs it down to just turning the PLC off is enough. Which comes full circle too. That might be enough, but yeah, yeah, in some cases it isn't.

SPEAKER_01 10:14

Yeah, I've heard PLCs characterize as dumb uh assets, and that's highly unfair because obviously they're they're carrying out very specific sensitive process work. So uh have you heard that characterization as well?

SPEAKER_00 10:29

Yeah, um I think it comes from the whole idea, like I mean that there's there's a lot to do with like whenever you speak to anyone about OT that isn't necessarily fully familiar, they'll just say it's just a load of old computers and like the references of like Windows XP being the main and main operating system in the environment. And by all means, many many environments that you find yourself in are maybe legacy and old, but even those, even the the other the environments that haven't been updated in 10-15 years, they're still quite advanced, in fairness. Um so these do still quite take a bit of learning once once you get in there and like and really to understand how you would manipulate it.

SPEAKER_01 11:05

I mean, this is really almost the realm of very advanced attackers if if you they're targeting PLCs, because I would imagine, and correct me if I'm wrong, you need some you need to do your homework on the vendor, on the controller, you need to understand the way it works, right? I mean what what kind of homework goes into this type of research from that angle?

SPEAKER_00 11:23

A lot. So you can categorize it as two kinds of things. Firstly, you need to know about the the actual the the background. How if you if you're attacking a water treatment provider, how is water treated in general? So how so what do those processes look like at an abstract level? And you also need to know how the the victim-specific vendor technology works as well, because those ecosystems are quite varied and they have different vulnerabilities, they have different things you can take advantage of. Um but also once you get in there, it's that case of process comprehension and really needing to understand what's unique to that environment you found yourself in as well.

SPEAKER_01 12:00

Alright, so tell me a little bit about your research, specifically the the living off the plant aspect of this. What I know you guys developed a technique.

SPEAKER_00 12:08

Um take me through it from a high level, just so the specific lateral movement technique that we've we've we've kind of spoken about here at our um at RSA this week is is essentially um abusing communications library functions that reside within Siemens PLCs. So they're called put and get. And put um essentially is a write function, it's how PLCs tell other PLCs or HMIs um specific uh well, you know, write things into remote PLCs memory. And get is basically how they can read remote memory from a PLC and bring it locally. And what that actually ends up being is a really neat read and write function. It takes a few extra steps to read and write every byte on an external PLC, but essentially what we found was that previous research where we were abusing the S7COM read and write function anyway, can just be replicated using put and get. So we can basically say, to get, read this byte, and then read another byte, and then read another byte, and then we bring that all locally and we can reconstruct it. And then once we've downloaded entire data blocks worth of memory, we can see the length of that data block and where certain zero bytes are that are always going to be there in specific data blocks, and then we can create signatures for or match signatures, I guess, that we've already created to identify which library functions are running on a PLC. And then once you know what library function is there, we know where the variables are in memory, so we can precisely know which variables are what and what values they have, and if we want to manipulate them, we can then write into those variables as well from a hop away. Um so yeah, it's it's it's it's quite a simple thing, really. It's it's it's basically using another PLC's read and write function. So it's it's quite simple, but um yeah, it's it's it's uh it's a bit of a brain melter to try and implement because of the amount of things you have to do, because you have to say read this from this external, put it in this local memory, and then we read that, and then we keep going around. So it's like it's about five or six steps. It gets extra confusing because we can chain these together. So we can do it from PLC1 to PLC two, but then we can see tell PLC one to tell PLC two to do it to PLC three at infinitum. Um so when we try to do it to three plcs, it's possible. It's very, very slow because we're doing about five um about five writes per each request. But it um but yeah, it works. It's just really confusing.

SPEAKER_01 14:34

And what kind of access would an attacker need? Is it local physical access or just network access.

SPEAKER_00 14:42

So if they've if they've compromised the machine on the OT network that has network access to the first PLC, they're basically ready to go. It just has to um the PLC has to have port 102 open, um, which is for S7COM, and it also has to have put and get already enabled and be configured to speak to another PLC. Uh and then we're just re just good to go.

SPEAKER_01 15:03

And are you bypassing any native protections or any features that are supposed to be are supposed to enable a little bit more security, a little bit more protection on the device?

SPEAKER_00 15:15

Um not really, no. So there are certain functions and features that can be implemented that may slow it down, that may make certain aspects difficult, or may make certain things not as good. But typically what we find is these kind of security controls are either just not implemented because they cause it compatibility issues with other devices on the network, or the system's integrator just hasn't bothered to implement them in the first place anyway. So typically what we find is this isn't wholly unrealistic to just say this is just gonna work carte blanche on most environments that you find this this kind of setup in.

SPEAKER_01 15:55

So what would some of the controls be?

SPEAKER_00 15:56

Just the authentication between the devices or so yeah, um I mean it it this this this affects like some more slightly legacy devices. So this is um mainly targeted at S7300 PLCs, um which are um fairly old now, but they're still very widely deployed. Sure. Um but again, so so the the actual enumeration, there's there's um there's a security control called block optimization, which makes it um it's makes it difficult for us to actually fingerprint the like what's going on on in memory, so we then can't really understand what's going on. But um they just they're just typically not not that frequently implemented. So um so we caveat this in the research. We we make sure that these things are known. Like there are certain things you can do, but they come themselves, like I say, with their own their own disadvantages of implementing them.

SPEAKER_01 16:48

So what would an attack look like?

SPEAKER_00 16:50

I mean, are you you're not in necessarily injecting code or no, um it I mean it it would it would so yeah, we're not injecting code, we're not like downloading configs to the PLCs. We're we're basically like being able to read read um the memory that's there and then write into it. So for example, um in the demo um that I presented today, um the idea was that we had access to one PLC that was acting essentially as a relay between another PLC on a remote site that was controlling a tank that had an inlet and an outlet valve, and it was also had a count feature so that it could only outlet 20 decolitres a day of fluid or whatever. And so what we did was we used the read function to enumerate what was on the PLC, we enumerated the count function, um, worked out what was there, and then wrote to the count function and overwrote where it was at, which was at 20, back to zero so that we could uh unload another 20 decoliters. And then we also overwrote the um the uh the the output in the valve outlet valve to basically make sure that the valve opened. So then we're basically overwriting actual operational variables that control the physical environment and also like manage how much the physical environment is constrained.

SPEAKER_01 18:13

So if you're not watching for these variable changes, it's it's these are pretty much undetectable until it's too late.

SPEAKER_00 18:20

I mean, they're expected. They're expected on the network as well. So if if we're if we're using them, how do you tell the difference betwe between an adversary telling a PLC to tell another PLC to do something, or the PLC just telling another PLC to do something because that's what it's supposed to be doing, which makes it incredibly difficult. That's w that's the same with um the stealth that comes with living off the land in IT. It's just the same. It's it's really difficult to defend against. Right. Which is one of those things when I release research like this, I always find it really difficult because people are like, so what? And it's like uh I kind of don't know. Like yeah, it's it's it's really difficult, and I think we have a big challenge on our hands to distinguish between legitimate and illegitimate traffic when they look almost identical.

SPEAKER_01 19:05

But the risk is disruption, damage, etc., correct? Yeah, significant.

SPEAKER_00 19:11

I mean, even even like long-term espionage, like um that that could be a feature as well if you're just reading from another PLC. Even just reading like how much fluid is in a tank over the course of a day, if that might be important to you for for corporate espionage, for example.

SPEAKER_01 19:26

And so you mentioned a couple of times that you use the the Siemens S7 in your research. Do you think other PLCs, other vendors are in scope as well?

SPEAKER_00 19:34

Or I'd be hesitant to say yes just because I haven't looked at them. Um but possibly. I don't think this is unusual functionality. Um it might be implemented different, or um I don't know. I think that may be the next step. Yeah. Um we might see if it if it exists in other vendors as well.

SPEAKER_01 19:56

And um I assume you brought this to Siemens.

SPEAKER_00 20:00

Um just curious as to, you know, in terms of a fix, I mean, is this kind of going back to the drawing board for them or so because it relates to one of the PLCs that's that's basically end of life, they they they they aren't regulated to to do that. They don't need to. So um so they aren't doing anything technically about it, but they they every time we come to them with some of like these really weird um vulnerabilities, this kind of thing, um they're really receptive, they're really good guys. Um they they'll put things in documentation, for example. Um so I mean it's it's the most that they can do really at this point, because they can't really be going and rolling out significant architectural fixes to something that is decades old at this point, and it would probably cause problems to the many environments that are using it right now as well. So it's difficult for them to try and do a technical fix.

SPEAKER_01 20:50

Yeah, and I mean that's a core OT problem across the board for a lot of these legacy assets that are out there. Um so what can defenders do about this? What should they be doing about it? I mean, if assuming somebody picks up your research and runs with it.

SPEAKER_00 21:06

I um I don't know. Um I one of the things that I I I kind of kind of tried to preach in the uh in in the takeaways of the talk was to do things like um sorry, I'm totally going blank. It's okay.

SPEAKER_01 21:31

The question was about what defenders could be doing about it.

SPEAKER_00 21:33

No, no, I'm trying to think of what it actually was. Oh so so for example, um to actually try and start detecting native traffic, um, using vendors that can can kind of pick up native protocols and things like that. Um like OT specific vendors, those are that are really like picking up like native traffic. Um and also focus on confidentiality as well. Um I know one of the main mantras in operational technology. Technology is to focus on safety and availability. And that makes a lot of sense. They are the priorities. But if you also consider the confidentiality of your your process data is really important, if you deprive an adversary of data about your environment, it makes it much harder for them to understand what's going on and for them to build up a more sophisticated attack. So they're not going to burn their access on an attack that they they aren't certain about. They're not going to just go and go ahead and do something when they think, oh, actually, this might just not work and we're going to burn our access. So what you're doing there is essentially finding out or giving yourself more time. And then a couple of other more long-term things I was suggesting as well were, for example, to actually train your OT cybersecurity staff on OT-specific training. Not just like the typical OT security training, but actual OT specific. Like whatever vendor that your your organization uses for PLCs, go on their training. So for example, if you work in water treatment, how is water treated? Do you know how that works? Do you know how that works in your specific environment? Because once you bring that back to the cybersecurity discipline, then you can start working out where the actual the like the crown jewels are, so to speak. And finally, having a more pessimistic view of there's there's there's there's a huge challenge in detecting this and even more so in preventing it. So start to think how you can build in uh resilience by design. So if things need to fail, open or close, do whatever is appropriate. If you can bacon redundancy so you can fail over to a different process, do that. If you can um, for example, have physical safety and security controls that aren't documented in the OT environment that are really difficult to find out, let that just implement those so that the adversary doesn't know that there's something there, and then they can't even circumvent it if they do know it's there because it's a physical control, not a secure like a cyber control. But otherwise, I don't know, I'm kind of I'm kind of at a loss myself.

SPEAKER_01 24:32

Yeah. Um so just as a final thought, do you think that data integrity, data protection is kind of like the next OT security discipline, maybe for lack of a better word?

SPEAKER_00 24:43

I don't think it's ever going to be more important than safety and availability. Um but I think we will start to see the value of data, whether that be current telemetry in the environment, or that is piping and instrumentation diagrams and things like that, and just how everything is is is put together. I think all of that is really useful to an adversary. And as this gets more challenging, as we face more adversaries that are getting better and building capability to be able to do this, and they become more common. I think any anything that we can do, like every little helps. So starting to deprive them of that information is is a valuable thing to do.

SPEAKER_01 25:27

Yeah. Alright, Rick. Thank you so much for joining me. Appreciate it. Thank you so much for having me.

SPEAKER_00 25:31

It's been really nice. Thank you. Cheers. Bye bye.