Dead Man’s PLC: Ransoming The Physical World Via Operational Technology - Ric Derbyshire

Good afternoon everybody and thank you so much for choosing to spend your time here with me today and also thank you very much to the besides Lancasher crew for uh providing me with the opportunity. As Dan mentioned, I'm Rick and I'm a principal security researcher at Orange Cyber Defense. What that means is I get to spend a lot of time asking weird and wonderful questions and seeing if we can find some interesting stories to tell about them. One of those weird and wonderful questions was, can we ransom operational technology? And that came to the story that I'm going to be telling you today, Dead Man's PLC, ransoming the physical world via operational technology. So, let's set some

context. There is a much vaunted OT apocalypse with oil refineries being taken down after cyber attacks on their industrial control systems. We have factories being taken down by cyber criminals attacking their precision robotics. We have entire cities being plunged into darkness due to nation state cyber attacks against their power grid. The eagle-eyed might notice that none of that is actually true. They were just made up. What we actually see is something very, very different. What you're seeing at the moment is a visualization of some of the data we've collected at Orange Cyber Defense over the past few years. And that data ranges from 1988 to 2024. And what it shows are cyber attacks that have had some sort of operational

technology impact. Now the years on the left hand side are grouped into 5-year bins. Um but as you can see around 2020 there's this kind of elephant in the room or elephant on the slide more uh to be more specific. in 2020 that's going across the top. What you might see is that those are predominantly conducted by criminals and then using predominantly IT tactics, techniques and procedures and predominantly targeting IT and they do hit level five of the pery model which I will explain later but that's really strange. Why are we seeing all of these IT targeted IT attacks impacting operational technology? Well, the reason is the advent of ransomware as a service and double extortion that kind of kicked off

and became a prolific problem in 2020. The reason this is impacting operational technology is twofold. The first reason is that maybe the the uh the victims just don't trust their security controls or just through an abundance of caution they either disconnect or turn off their operational technology. And the other reason is that perhaps there are dependencies that the OT relies on within the IT that may get encrypted or ransomed, but that's really weird because these are still affecting operational technology. So if we take a very brief and non-comprehensive look at the cyber extortion kill chain, what you can see is there are a veritable number of technical ways to skin a cat. And what we get to at the end is the seven

criteria on the right, which are essentially a crime at the end of the day. To be able to do some sort of extortion crime in the cyber domain, you still need to have a threat. You need to have a demand. You need to have proof of life. You need to pressure them. You need to be able to facilitate a negotiation, receive a payment and then return what has been ransomed. But that is a crime. So if we start looking at this as a crime rather than a technological issue, we can start to involve uh criminological frameworks such as routine activity theory. So routine activity theory has three main pillars that basically need to be there

for the crime to be perpetrated. The first is there needs to be a likely offender which must have uh the capability, the motivation and the viable motus operandi to be able to actually do the crime. There needs to be a suitable target. So a victim who has a vulnerable enough attack surface and also presents the criminal with enough time to do their crime. And there has to be an absence of a capable guardian. And with cyber crime, that kind of follows two different strands. So typical law enforcement, which is there for every type of crime, which as people in this room probably know, is struggling to keep up with the cyber crime ecosystem, but also the technical controls as well.

So if we continue back on the OT narrative, we can see that the uh the second and third pillars are still there for operational technology. There are absolutely suitable targets that are suitably vulnerable and afford enough time for cyber criminals to do what they want to do. And also the absence of a capable guardian. Law enforcement is no different for IT and OT. And technical controls, if anything, are more difficult to implement in an OT environment. So what we're missing is something from the likely offender. And specifically within that, it's a viable modus operandi. And what that boils down to is being able to monetize cyber attacks on operational technology. So I want to take you back

to the OT context for those in the room that may not be familiar before we continue down that road. So a brief primer on the two main categories of device that may uh that may be important to the rest of the talk. First on the left is the programmable logic controller which is the heart of the OT environment. This takes a configuration from an engineer and then uses that configuration to sense the environment around it and then actuate it in accordance with its configuration. So this could mean understanding what's in uh in a tank and changing pumps and valves or it could be um uh doing something with a robot on a uh manufacturing line. Moving over to the

right we have the human machine interface which is essentially a way for the engineer to interact directly with the physical environment. This may be a touch screen. It may be a Windows device. But what you'll typically see is a diagram known as a mimic on screen. And then the engineer can kind of make small adjustments on the fly. I mentioned the Pergeue model before very briefly and this is the Pergeue model or more specifically the Pergeu enterprise reference architecture. And what this is is not an actual architecture on which to build your operational technology but more of a conversation piece and to kind of have a kind of like a language to talk to other people and understand where

certain assets may be. The the three things I want to um draw your eye to are in the orange dashed boxes. So at the top we have levels four and five which are the typical IT environment which you may be familiar with already. And then the bottom uh box is the operational technology. So they are levels three down to zero which get progressively closer to the physical environment as you go down. And then in the middle is the allimportant demilitarized zone the artist formerly known as air gap. And then I also had a couple of other categories within that visualization that I want to quickly explain with a taxonomy that we created simply to really understand the data

that we were looking at when we were creating our data set. So we split this first into two categories. those ex those attacks that exclusively use IT tactics, techniques, and procedures or TTPs. And those also included the use of OTTPs. For category 1 with the ITTPs, we then split that into how the targeting kind of occurred. So 1 A is just the IT itself was targeted. 1 B was where there was IT and OT targeting where the attacker may have opportunistically or accidentally spilled into the oper uh the operational technology environment. And then 1 C which is quite rare is where the adversary uses ITPS against things within the OT environment thinks Windows desktops think servers and

things like that. Obviously for category 2 if we're going to be using OTTPs the OT has to be targeted. So we couldn't split that that way. So we split it into sophistication. And there are two very distinct types of attacks that we witness in operational technology. Those that are very crude and those that are very sophisticated. The crude attacks are where an adversary just gets into the environment and uses commercial off-the-shelf tools or whatever like uh metas-ploit modules or just brute forcing human machine interfaces to essentially do something anything that they can. The sophisticated attacks are where the adversary has a much more um meaningful and desired impact and therefore they'll use a tactic that is

unique to an operational technology attack known as process comprehension. And that's where they understand or build an understanding of how the physical environment and the operational technology are configured and how they work together to then optimize their attack and do something that has true meaning to them. So when we're talking about ransoming operational technology, we take it we're taking it from over on 1A all the way to 2B. And what we want to do is create some sort of sophisticated attack that can then optimize an a ransom on operational technology. To do that, we need a few criteria or we need to achieve a few criteria. So the first is it needs to be scalable. We

can't just take the typical encryptionbased ransomware approach to operational technology. If we tried to encrypt a programmable logic controller, then it's not really going to work. Even within one facility, the diversity is so large that it would be difficult to scale. So one facility may use multiple vendor ecosystems and within that ecosystem multiple models and within those models multiple firmware versions which all may require different vulnerabilities. We need to keep it stable. The typical approach for ransom is to complete to to cause complete instability to begin with. But that disincentivized payments from an operational technology perspective because if your factory or your power plant has already gone offline, there is no incentive to pay and the incentive is

actually just to rebuild and ignore the attackers. So we need to keep it stable and we also need to have a credible threat which takes us to our next criterion, the credible threat. So, we need to truly understand the environment to be able to say that if you don't pay or if you try and tamper with our attack, we're going to cause serious consequences that are going to cause safety issues and they're going to cause you financial issues as well. And because we're leaving the environment stable during the attack, we need to be then be able to detect tampering and prevent recovery, which are our next two criteria. So, we need to be able to make

sure that while things are stable, the victim doesn't try and check out what we're doing and tamper with it or even try and recover from it by introducing a programming device and disabling things. And then finally, we need to be able to disarm on payment because we're cyber criminals, but we're trustworthy cyber criminals. So, if we're going to go to a second victim, they have to know that the first victim actually did get their facility back once they paid. So we achieved this click by developing dead man's PLC. So if we go back to the cyber extortion kill chain that I showed you before, what we can see is if we change that to the dead man's PLC killchain, if

you will, there's very little difference and we still kind of follow the same style of uh killchain. And what's very crucial is we still end up at that thing on the right, those seven criteria to commit a crime. So I'm going to talk about how it works first which will be an uh a kind of overview of an implementation which will show screenshots and it will also show a diagram that we build up very simply and then I'm going to talk about why it works and we'll look at some animations and some videos. So if you focus on dead man's PLC um the three deviations from the other kill chain are the intrusion positioning and threat model. They are

the internal reconnaissance and preparing Dead Man's PLC. And then there's deploying and arming Dead Man's PLC. If we look straight towards the intrusion positioning and threat model, we start at the engineering workstation, which is the typical desktop device that's used to configure the programmable logic controllers and essentially give controls out to the entire facility. Now, that's may seem unrealistic because we have to get through over the internet through the enterprise network through the demilitarized zone and then to the engineering workstation. But attacks that actually target operational technology of those a third tend to uh stem out from the engineering workstation. So this isn't as unrealistic as it may seem. So if we start with the internal

reconnaissance, here's us. Here's our engineering workstation. And the first thing we want to do is identify and validate the current PLC project. We want to know what's going on. So if we have a look at our screen, what we can see is the seaman's tier portal. And for some foreshadowing, we're going to be using the seammen's ecosystem for the rest of this talk, but any ecosystem is available. So, what we can see here, although it may be small on the screen, unfortunately, are a few little uh green boxes that show that the PLC's that we're looking at and their configuration are live and they are on the working PLC's as well. So, now we already know

the PLC's that exist and we know that we have access to them. Click. and we know that the code running on them is valid. The next thing we want to do is identify pre-existing PLC to PLC relationships. Basically, where the PLC's are talking to one another because we're going to build on that later. So that may look a little bit like this on our screen. And then if we build our diagram, this is not the same as the screenshot. It's just for uh for illustrative purposes. It may look like this that the PLC's are talking to one another. The next thing we want to do is identify core code blocks. So things that are running on the

PLC's that may look a little bit like this. And for our demo, this is actually the the main code block that stems everything else stems out of. And what the reason why we need to know this and know about the code is because first we need to keep that stability. So we need to make sure that whatever we implement doesn't affect the stability of the the legitimate code on the system. But also by getting a good understanding of this code, what we also know is how to optimize the the consequences if we need to enact them. So now we have that. We know how to keep our environment stable and we also know how to enact the most

optimized consequences that we actually want to. So we've done our reconnaissance and now we need to deploy and arm dead man's PLC. The first thing we need to do is introduce a covert monitoring network. And the way we do that, oh nope, sorry, I need to do the diagram again. Um, we're going to take our lines away because we're going to build our own lines now. So, this is where we're at right now. The first thing what we're going to do is build a heartbeat network in. And what that does is it means that every single asset under our control has mutual accountability with one another. So, if a sender cannot send um a heartbeat to a receiver, it knows that

the receiver has been tampered with. And vice versa, if the receiver does not receive something, it knows the sender has been tampered with. This basically acts as a dead man switch throughout the entire network which is where we get our name Dead Man's PLC. Snap 7 there as well is um py the Python library for interacting with the S7 comp protocol from Seammens and that's how we include desktop devices in our attack as well as just as well as PLC's. Now we do have mutual accountability but that doesn't mean that all the devices snitch on one another. So we need to introduce alerting as well. So if a device does detect that there has been a tampering

or some sort of uh recovery attempt, what we do is we flip an alert bit and then we propagate that throughout the entire network within less than a second such that as soon as anyone tries to tamper or do anything, we set the we propagate out an alert and then we start enacting the consequences. These are done via basic things that already exist within the seaman's library function. So these aren't things that we've had to implement. They are quite literally drag and drop. So now what we have is our heartbeats going throughout the network and our alerting system ready to snitch on all the devices. So then we need to prevent recovery devices as well. So this is

really simple. Once we push dead man's PLC out to the devices, we take a baseline of the connections that are expected to that device and if they deviate whether up or down, we then change that alert bit and then the alerts propagate throughout the system. It looks a little bit like that cute little watchdog camera there. So then we need to introduce a payment limit as well, right? Because if we're remaining stable throughout the environment, we can't just leave it stable forever. There has to be some consequences. And this is possibly the easiest thing. We literally just set a timer on all the assets that's synced up. And then if the timer runs out, the

alerts propagate and everything goes wrong. So that looks like a cute little 24-hour clock on the engineering workstation there. And then we need to introduce code to disrupt the process. We need that credible threat. So that top screenshot is what I showed you before when I talked about identifying core code blocks. But this time we have a little gateway there so that if an alert does actually propagate, we stop that code running. All of the legitimate code will cease which already causes issues for the operational environment. But what we do as well is we find out how best to destroy the operational environment. And then if those alerts do propagate, we enable our malicious code and then that

rips through the the physical world. That's on the bottom. So we can see that the alert kind of the gate isn't set yet. And then but if it is set, we have some bits of code that stem off from there. For our demo environment, it's really simple. It's not super optimized. Um but you'll see that shortly anyway. So now we have a way of removing the heartbeats. they will stop the alerts will propagate out and then the consequences will be enacted should we need to enact them then we need to prevent the victims from reversing changes which is actually probably the most simple parts can be password protected but because of usually the geographical um

the geographical range or perhaps in an event of an incident we don't want to be typing in a long and complex password if something's about to explode or something else is on fire so instead Instead, usually um operators will just tend to not have passwords and we can use that to our advantage and start password protecting everything once we deploy our attack. So then we have little padlocks everywhere as well. And then the last thing we need to do is arm dead man's PLC. So we're going to take out those heartbeats and those alerts for now because actually we haven't deployed this at all. We've just been building this configuration locally. So the first thing that we need to do is finally add

into the configuration a small way of arming the um arming the attack because if we deploy it already armed while it's uploading or actually called downloading to the programmable logic controllers there may be instability there and we want to be able to do that once everything has actually um been downloaded. So that means we then download everything the existing code and dead man's PLC and then we can arm it and then the only thing left to do is the crime itself. So I want to talk very briefly about why this works as well because this sounds like science fiction right now but this is a legitimate way of of doing an attack. So the first thing is that once

we've armed dead man's PLC the alerts and the heartbeats will talk to one another the entire time or so the devices will talk to one another with the alerts and heartbeats and these are constantly checking on one another to make sure that nothing happens. So, I've got I don't know if this is going to look well look good on the screen, but what we have here before I start the video is Seaman's tier portal, which is like the main screen window. And then the smaller box is um our command prompt that allows us to enable the attack. So, if I press play, we say that we want to uh arm the attack. We'll have a payment window pop up that we're not

going to use just yet. And then what we can see is that little green lights will start flashing which shows the heartbeats sending to sending to one another. And that's that. But what happens if Debman's PLC is tampered with? Because that's the most important part, right? So if for example they want to try and recover one of the um one of the programmable logic controllers, say number three down at the bottom right. They try and pull that out and the heartbeats cannot reach it. Uh and the alerts propagate out and our consequences uh are ensued. So I'd like to introduce you to conveyor.exe, exe the OT equivalent to calc.exe. And here we have our lovely

little factory which just has what? It looks really slow. It has one uh conveyor in, one conveyor out, and a robot moving the boxes. It's very, very simple. So, we move over to our attack and we arm it and we get rid of that pesky payment window. Again, we can verify that the heartbeats are sending towards one another. And then we can go and check with the physical or virtualized physical environment to make sure that everything is still running and stable because we want to remain stable until the consequences should be triggered. Everything in the land of conveyor.exe is fine. The boxes are being moved about happily. But what happens? The victims now want to try and recover. So they

pull a PLC out. There's a very handsome hand on screen pulling out a network uh cable and then immediately the heartbeat cannot be received by that device and it doesn't send any and the alerts propagate out. And then if we go and check on conveyor.exe we see the timing on these is so bad. We see that everything is going a little bit pear-shaped. Cool. But if we're leaving the the uh the environment stable, we also have to have this timer that I mentioned. So what happens if they just decide to call our bluff and not pay? Well, in which case, we also have to be able to enact the same consequences by stopping the heartbeats and propagating the alerts

out. Again, we're going to go through the rigmarole of checking on conveyor.exe. Everything is working fine. And then we'll go over and arm dead man's PLC one more time. I'm pretty sure I set the timer for 10 seconds on this video, so I might have to speak quickly here. We get a rid of the um the payment window. Go quickly check that everything still remains stable because that's again one of our criteria. And then the timer is running out about now. The heartbeats will stop, the alerts will propagate, and conveyor.exe is once again having a bad time. And for one last thing, what happens if the victim caves and pays us? Well, in which case, it's really simple. We ask

for money, they give us money, we stop everything, and we disarm Dead Man's PLC, and they get the benefit of having their facility back under their own control. Again, for the last time of conveyor.exe, everything is working fine. Unfortunately, this time, with any luck, it will remain fine. We go and arm dead man's PLC again, but this time we won't get rid of the payment window. And just for one last time, we'll go quickly check that the environment is still stable to prove that everything is working okay. And it is fortunately. But then the victims have caved and they paid us. So we give them the super secret key of 1 2 3 4 and they pay and everything is

disarmed and we go and check and conveyor.exe lives to move boxes another day. So what about defenses? Because this is just messing with configurations. There are actually a number of defenses that you can do prior to the deployment. If you want to do it from a network perspective, you can follow best practice network segregation. You can have a good demilitarized zone that doesn't allow attackers through. You can split your operational technology environment down into as granular cells as possible so that this is more difficult to propagate. On the engineering workstation, these are typically just normal desktop devices which are just as easy to secure easy I say to secure as uh any other desktop device. But with

the added bonus of this configuration software we've been using uh can actually have a second factor of authentication in the form of a USB stick that has a license on it which will means the software won't run if the USB stick is not plugged in and that helps to follow that procedure and not leave it plugged in all the time. And then finally for the programmable uh logic controllers you can password protect them. It doesn't have to be super super complex and long to type in, but it can even a little password is going to help better than none at all. And also you can leave the PLC's in running mode rather than configuration mode. But what happens if Dead Man's PLC

has been deployed and armed? We've spoken about this around the world and we've spoken to people and redteamed um how we would actually recover from this in that event. And so far we have come up with absolutely nothing saved from a graceless shutdown of the facility which is going to take weeks or even months to recover from and that's going to end up inevitably being more costly than a ransom payment. So I'm going to leave you with a few takeaways just basically highlighting the key points of the talk. attacks that impact OT environments are indeed increasing. You may be seeing that around in terms of marketing and it's true, but it's only because of things like cyber extortion against IT

environments. At the moment, we're not really seeing that many sophisticated attacks against operational technology. A viable modus operandi is all that criminals need to actually target operational technology with crime and extortion. This is all possible as you've seen today while living off the land without any zero days or even any exploits. This all can be done just from the engineering workstation. And finally, good or even best if you will practice will prevent deadmines PLC from deploying. But once it has been deployed, there is not much you can do. Thank you very much. That's me. There's a QR code on the top. Yeah, right. Oh, no, it's your left. Top left. um of the paper um that

this work is based on and also if you want to read more about the stats that we collect uh our in cyber defenses security navigator is our annual report um and my content for this year is on page 78 so please do check that out thank you very much thank you thank you very much um I think we've got Helen at the back Helen come down uh whilst uh Helen's setting up um does anybody have any questions for Rick Stunned silence. No, no, nobody cares about you. Oh, one, one, two. Okay, two questions. Great. Uh, I will give this to you and then I'll help Helen set up and then the very aute man there with

the purple jacket. Thank you. Yeah. So, that that was interesting. Have you considered that or is there any scope for using a similar technique in a sort of defensive capability? So setting up monitoring that does heartbeats, does uh integrity checking of the PLTs that are present in order to counter someone doing something like this. That's where this actually came from. Interestingly, we thought about the idea of doing it as a defensive mechanism first. Um there is a company in the US that actually do this where um they go into facilities and will modify the configuration files to to act as canaries essentially. Um I don't know how well they're doing. I hope they're doing really well cuz it's

a really interesting idea. Um, but I I haven't really looked into it personally other than going actually we could do this offensively that sounds more fun. Uh, so that's what we did. But yeah, absolutely. If you could just pass it to the gentleman at the back there. Peer-to-peer microphones. Thank you. um after the victim is paid and uh would you then remove dead man's PLC from the uh PLC or or or is it left there afterwards or It will be left there. So we just simply disarm it. Um which in our really rudimentary demo was just like changing flipping a boolean from one to zero. Um but what we do then is release like the engineering

workstation for example and then they can just remove it themselves. And what's probably easier for them is just recovering from backups. So typically any environment even if it's you know a small factory will have really quite rigorous backups of their operational technology. So they'll just go to the backups and then put uh redownload those. Cool. Thank you very much. I'll go get rescue the microphone.