Okay, hello, everyone. My name is Joe Slowik, and I am going to be talking about something I call mission kill, focusing on process targeting and ICS attacks. So getting into that first, who am I? So currently I am a adversary hunter,

a fancy way of saying threat intelligence, I suppose, working at Dragos, focusing on industrial control system threats and threat activities. I also do some cyber threat intelligence training through a side gig called Paralis. If you're hanging around the blue team village,

you'll see me with a workshop on cyber threat intelligence later today. But in addition to my current time, working with Dragos on ICS threats, I formerly led the incident response team at Los Alamos National Laboratory and did some cidery things for the US Navy as an officer back in the day.

But enough about me, we really wanna get to our agenda for today. And along those lines, we're gonna start with just a definition of what an attack means. There's a lot of confusion around the word, and so just get a common conception of what the term means in the context of ICS events.

And then review three process targeting incidents from the past few years and what those teach us in the consequences of seeing adversaries migrate into a more refined or a more focused way of trying to impact control system environments and conclude with defensive options and implications

for what it is that asset owners and operators need to do in order to meet this type of or category of threat. So first to define attack, principally, I'm looking at attack as being those deny, degrade, destroy operations. So just simply scanning a device, sending a phishing message,

don't really constitute attacks. These can come into play in terms of certain preparatory actions, but trying to determine what is simply a route to economic espionage versus what is a precursor to an attack really depends upon being able to discern

or identify adversary intent. And short of being able to read minds, it's very hard to do that. So really for the purposes of this discussion, we're really only talking about those sorts of incidents where there has been noticeable process, disruption, degradation, or denying control over an industrial process.

So looking at that and we can map this and there are several ways of doing this. There's the ICS specific kill chain, as well as the various other kill chains that are out there. Since we can't just have one, we need multiple, but really looking at a sequence of events going from typically breaching a victim's IT network,

identifying points of contact with the industrial environment, enumerating and categorizing that environment in order to determine what sort of capabilities are necessary in order to interact with or make some change or disruptive effect within that environment. And then finally being in a position

to deliver effects on objectives. So a sequence of events that are interdependent, that if you fail in one, you essentially fail in all, that defines what it is is required in order to execute something disruptive or destructive within an industrial environment. And so with that in mind, looking at a lot of headlines,

we see things that are mentioned as attacks that really don't meet that bar, whether we have items like the infamous dam, New York dam incident from almost 10 years ago now, to items like the Baku, Sehan, Tbilisi pipeline incident, or even just plain made up items like in the wild ransomware

that was a company tech demo and whatnot, that we see the word attack thrown about quite frequently, but done so in ways that really don't align well with a conception of what an attack really means or where the implications are quite real. We do, however, see general attacks that impact ICS.

So whether we're looking at something like the Shamoon event or the sequence of Shamoon events since the first one in 2012, moving on to items like there was a recent, very interesting event that took place in the United States just last year, where there was a denial of service condition on a router that inhibited control

over a wind farm for a period of time. But while concerning, it seemed very untargeted. And then getting into things like various ransomware strains that migrate into and have some impact on industrial operations. While all of these are very concerning, they're also somewhat dumb or very untargeted

and kind of sloppy in impact. They're not terribly focused and not really taking into consideration the nature of or the specifics of the targeted industrial environment or the underlying process. Because today what we wanna talk about is a more focused type of attack that I refer to as process targeting, where instead of just blindly looking

to disrupt whatever's reachable within an environment, attackers instead focus on a specific stage or aspect of an industrial process. And this could be technical, such as looking for specific equipment or software, targeting a known vulnerability or something along those lines, or it could be operational, the understanding what the sequence of events required

for an industrial process, such as a manufacturing line that goes through three distinct states and knowing which is a critical path node that if it's disrupted, it results in the entire line being brought down, or presents a more operational way of looking at things and targeting those sorts of weak points.

And so we're really trying to move away from the discussions on indiscriminate wiping, ransomware, worms, et cetera, which define most of the industrial impacting events that we've seen thus far. But the thing is, they don't just describe all of the industrial events that we've seen to date, because there are a subset of industrial impacting events,

some in cyber, but one that's actually physical that I think presents some very important lessons. And so I'm going to bring that into the discussion today that represent true process targeting for impacts in industrial control environments. So we'll talk to the 2016 Ukraine event, which involved the crash over rod malware, also referred to as InDestroyer,

the 2017 Saudi Arabia incident that involved the use of the Triton or Trisys malware. And then talk about something that happened in Saudi Arabia in 2019 that wasn't cyber in origin, but really emphasizes how attackers are evolving when it comes to operating in industrial spaces. So first, the crash override incident.

This was something that was briefed at Black Hat a couple of years ago between myself and some Dragos colleagues, as well as Anton Chirpinov and Robert Lepofsky of ESET. An interesting event in that it represented the second cyber event impacting electric operations in Ukraine after the 2015 incident.

But the 2016 event was a little bit more interesting because it represented a technical evolution in that it introduced a specific piece of malware with capabilities for manipulating the distribution, well, transmission operations within a substation in order to cause a disruption of the delivery of power.

So the way that this attack worked is first penetrate the industrial environment and place malware on computers that can communicate to the field devices that actually control the breakers, then schedule that malware in order to open breakers at the target transmission site to do a sort of coordinated effort.

And then there was some after effect limited system wipe and some disabling events on infected machines that induced the loss of at least logical or state of control in the specific environment. And then there was this thing that at least at the time, and I've since analyzed this quite extensively

in my presentation at the ICS village last year, actually, as well as in a subsequent white paper on a protective relay denial of service that took place post-attack, which actually starts to become more significant when you look at this attack in terms of process dependencies. Because when we start looking back at 2015, the attackers used a wiper a sensibly to delay recovery in 2015,

that we will disable all of the SCADA workstations, all the engineering workstations in order to inhibit the ability to restore operations in an effective and efficient way. But from the 2015 attack, it was proved that the operators in question were quite happy and willing to rapidly shift into manual operations

in order to restore electric service as quickly as possible. And we can assume that the attackers weren't stupid, and there are significant pieces of evidence that have been reported publicly, as well as a lot of things I've written privately, that the attackers in these incidents, if not are the same, or at least are very much tightly linked, that they took note and that the wiper functionality in 2016

really seems kind of superfluous if you know that the operators are going to go out to the transmission yard and start closing breakers manually. So other than just being an asshole and wiping computers and making restoration just more painful in the long term, why would you do this? Well, it seems that instead the wiper was intended for other purposes,

that rather than to inhibit restoration, because you know that the operators are going to get into manual operations, instead the wiper seems more aligned with eliminating logical view and control of the SCADA environment. And that brings us to protective relays, because that denial of service condition on protective relays becomes fairly significant when you realize what a protective relay does

in the context of electric utility operations. So especially a digital protective relay is a smart device that works to ensure the process, maybe not necessarily safety, but certainly process control and certain degrees of process protection to make sure that fluctuations

in electric distribution and transmission operations don't propagate beyond the relay operations in order to induce potential physical damage to electric distribution, transmission, or even generation gear. So looking at this is that we see protective relays as being a significant aspect of electric operations at multiple stages of the electric utility landscape.

And while you can operate without them, it induces a certain level of risk in that fluctuations, normal fluctuations is the part of electric operations, let alone the introduction of potential disasters, natural or engineered, means that with the absence of relay protection,

anomalous events would propagate beyond that protective layer to start impacting equipment directly, thus creating the preconditions for physical equipment damage. So looking at the event in Ukraine, the Siemens SuperTech denial of service is pretty interesting in that it doesn't take the device offline, but rather the denial of service

wipes all the protective logic from it. It's one of those, this is a feature as opposed to a bug in that it's used to free up memory to allow for a firmware upgrade or a reprogramming of the device. So the device is still network accessible, it looks powered on. So if you're running through the yard trying to figure out what's going on

or through the control room, it might look like the device is still up and running, but all the actual protection logic is removed so it's not doing its job. And it's a trivial attack to execute just by sending a single UDP packet within the environment. It is worth noting that there was an ending mistake in the malware, not sure if they were counting on this being translated in some fashion,

although working in a lab environment, not quite sure how this was supposed to have worked, but it doesn't look like the payload would have been delivered properly, at least in the actual attack. And this was one of a number of mistakes that were made as part of the crash override event. But even though it didn't work quite as to the extent or in the fashion that the attackers wanted to,

the intentions and the capabilities deployed in the 2016 Ukraine incident show a much more ambitious event than what we saw in 2015, in that the attackers induced a widespread outage and a loss of U condition through that wiping aspect, and then removed line protection from transmission operations. Now removing line protection on a de-energized line

makes no sense when you think about it, but if you're anticipating that operators will rush to restore operations irrespective of their ability to ascertain the process safety and protection of the environment, now you're setting up a staged attack where there's potential physically destructive consequences when you restore power to those de-energized lines

in the absence of process protection. So while it didn't work as intended, crash override appears as though it was designed to try to achieve physical process destruction within the context of electric transmission operations that would have had disruptive effects lasting potentially months in order to try

to restore, recover, and ultimately likely replace damaged gear. And a lot of this comes from knowing both the combination of how the operators in question worked within their environment, as well as the importance of protective relays for electric operations. Moving on to 2017, we had the Triton-Trisis incident

at a petrochemical facility in Saudi Arabia. And there was much discussion at the time about Triton-Trisis as being malware that can kill and who is behind it, is it Iran, is it Russia, or is it some other entity? But a lot of the discussion really masked some of the subtleties and really quite interesting technical details around what Trisis was capable of

and how it would work as part of a overall attack sequence. Because again, similar to what we saw in 2016, Triton-Trisis was not a bolt from the blue, but rather the end result, well not even the end result as we'll see shortly, in a sequence of events to achieve physical process

disruption or destruction within the victim environment. So we have a combination of items of repeated credential harvesting and reuse to pivot around the environment and to replay access through legitimate VPNs in order to get remote access into the ICS environment, continuing to pivot through credential capture until the attacker is able to get direct communication

to a safety instrumented system on which Trisis could be deployed. And that's an interesting part and requires us to understand what a safety instrumented system is within the context of industrial operations generally and petrochemical facilities specifically. Because safety systems, while they don't ensure that nothing bad ever does happen,

a safety instrumented system typically acts as sort of an emergency control system in parallel to the basic or operator controlled environment, such that in the event of a hazardous or dangerous set of conditions within the plant environment, that automated controls are put into place to ensure a easier or less physically disruptive

recovery of the plant environment to minimize damage disruption and facilitate recovery. Now there are certainly additional safeguards within plant environments from blowout valves and pressure release valves and other sorts of items that act as engineering layers of safety control,

but these start getting into more difficult circumstances for recovery and may have potentially hazardous conditions of themselves, like if you're venting product or even high pressure, high temperature steam in order to reduce pressure in an environment that could lead to physically hazardous conditions. So while just because you remove the safety layer doesn't mean that you're setting up a plant

for absolute tremendous levels of destruction, it still makes for a very hazardous environment where potentially nasty things can take place. If we start looking at Triton trices, it becomes important to note that the intrusion itself wasn't just focused in the safety layer, but in talking with the incident responders who worked on the event, the compromise took place through both the safety layer

as well as within the plant distributed control system environment. Using those compromises in parallel, a modification of safety settings means that you can have a manipulation on the DCS side that could cause a hazardous condition and then allow it to propagate through the safety layer in order to produce a hazardous effect

within the environment in question. And this combined intrusion and the interdependency between the two requires some understanding and knowledge of how these different items interact with each other and what sort of changes or what sort of actions you can take that would allow for a cyber action to propagate into actual physical disruption

as opposed to merely a plant denial of service. Because what's interesting about this is that Triton trices, kind of like the 2016 event, didn't work, at least not as the attacker's intended. So whereas it looks like the intended attack was to modify the cyst to eliminate the safety layer, then leverage compromise of the DCS in order to produce a dangerous state

that would then propagate beyond the safety layer to cause physical process disruption, instead of the time of installation of the trices malware, which happened not just once, but twice, at least twice, within the environment that a error or something else within how the malware was put together caused the safety system to trip. And as a result, the plant shut down,

which is still very disruptive and not a nice thing and cost a lot of money, but doesn't result in the sort of damage that would have happened had this attack actually worked as it looked like it was designed or intended to be carried out. So again, attackers are getting smarter in terms of knowing what sort of things to look for within industrial environments to sort of maximize damage, but still showing that they have a ways to go

before being able to do so successfully or at least on a consistent basis. Which brings us to something very interesting and a little bit more blunt than some of the cyber operations we've been talking about so far. Now in September of 2019, there was a very interesting event that took place in Saudi Arabia, again, Saudi Arabia, where there was a drone and missile strike

on two facilities in Saudi Arabia, the petrochemical facility at Abqaiq and the oil production facilities at the Kuryas field within the country. So certainly very alarming, very concerning, but what the hell does this have to do with cyber and why are you bringing this up, Joe? Well, the reason is that for one,

this represents the continuation of a series of events, both cyber and physical against Saudi oil infrastructure from the Shamut events to multiple physical disruptive and similar drone strikes, both on cross country pipeline operations, as well as oil and gas production facilities. But what makes the September 2019 incident

especially interesting is that it was very focused on a specific aspect of Saudi oil and gas operations that show a level of knowledge about how the Saudi oil and gas sector works. And going back to the idea of process specific understanding and targeting. Because when we look at Abqaiq, it is the world's largest oil processing

and crude stabilization facility. Essentially Abqaiq serves as the linchpin for the entire Saudi, well, for the majority of Saudi oil production in sweetening otherwise sour crude so that it is easier to sell and more acceptable to world markets. Essentially, if you take out the Abqaiq facility or its ability to operate,

the ability for Saudi Arabia to produce oil that the market desires becomes severely degraded and thus producing significant economic disruption as a result of physical disruption. Because looking at the sweetening operations or the desulfurization of removal of oil

or removal of sulfur from crude oil, it's a very complex chemical operation that requires a significant investment in equipment, fairly large physical footprint for plant operations. And as a result, something that represents a fairly big target. And it's been one that's been targeted at least in the context of Abqaiq several times previously, but through rather blunt measures

such as car bombs and other operations. Whereas the 2019 strike showed a very specific targeting because if we look at after action reports of the damage, we see that a lot of the primary focus of the attack wasn't on things like oil storage facilities or pumping and transportation infrastructure,

but rather on the vessels and cracking facilities required to perform the hydro desulfurization of crude oil to make it acceptable and for the market or able to export it. So again, a very focused attack on a very specific aspect of the Saudi oil industry that shows an understanding of a critical process node or path dependency

within Saudi oil operations that could allow for a significantly magnified impact as a result of just attacking one physical component of Saudi oil and gas infrastructure. So targeting the hydro desulfurization facilities would significantly limit Saudi ability to export oil to market.

And it did for a while and there was a significant effort placed into trying to restore these operations as rapidly as possible to try and recover. But as a result, the attacker was able to maximize a fairly limited strike by making sure they targeted just the right facilities in order to cause a magnified impact far out of scope or at least seemingly out of scope

or at least beyond the immediate impacts of just physical process disruption. So understanding how these things tie together enables for a much more powerful, much more impactful attack than just simply lobbing bombs into the Abqaiq facility and hoping for the best. So where does that take us? Well, it shows that attackers are starting

to get a little bit smarter in what they're shooting for when it comes to trying to disrupt industrial environments, whether that comes through cyber operations like we saw in the 2016 Ukraine event and the 2017 Saudi event, as well as through physical operations such as the Abqaiq drone and missile strike. Because what we're seeing is that adversaries

are learning about how these operations work and that increased knowledge yields an understanding of functional dependencies within these environments that allow us for adversaries to engage in focused targeting so that they can increase the effectiveness and the disruptive capability of strikes no matter how they happen to be executed within plant environments.

And we're looking at these focus points on the three items that we covered in the examples today. On process protection, the ability to make sure that industrial environments remain in a fashion that avoids physical damage and disruption to the equipment in question. Process safety to make sure that equipment is not able to or at least has sufficient safeguards

in place so as not to risk the safety or effectiveness of equipment or potentially causing harm to personnel within the plant environment. As well as process dependencies, looking at how critical a single facility like Abqaiq would be to the overall export of petroleum products for the Kingdom of Saudi Arabia. And the risks of this and the implications

are that attackers by being able to focus on specific aspects of industrial operations open up very interesting avenues for what kind of damage they can cause. Everything from making sure they could cause more focused and potentially longer lasting process disruption thus increasing downtime towards in scarier items like a potential loss

of life scenario which may have manifested had trices actually worked out as it was intended or physical damage like was the, which was the likely intention in the 2016 Ukraine event. So looking at this, we're seeing adversaries evolve over time from rather blunt and somewhat simplistic attacks like IT based wipers

such as the Shamoon events and some other incidents where just deploy something that worms through the network and cause as much disruption as you can in a fairly untargeted and widespread fashion. Then getting into more untargeted disruption just trying to disconnect processes and inhibit control something like we saw with the 2015 Ukraine event

and then getting into more advanced and more specific targeting such as the focus on protective relays in 2016, the focus on safety systems in 2017 or the focus on hydro desulfurization operations in the 2019 kinetic strike. What we do about this is an open question though

because when we look at defense in a classical sense, we usually think of throwing up walls and trying to keep adversaries out. And while this is not necessarily a bad thing and we certainly want to keep adversaries out, this is a very limited view and not necessarily helpful in trying to really adapt with how adversaries are shifting when it comes to trying to impact

industrial environments. Because looking at industrial environments, we have the combination of not just IT based or IT like equipment, which is amenable to IT like controls, but also combined with that the physical process environment, both in terms of what the environment is designed to do as well as the implications of undesired

or unintentional modifications to that environment that can cause disruption and potentially even damage. So instead we need to have process aware defense as part of ICS operations where traditional IT centric defense certainly forms a major plank of what we're trying to do because we have lots of information systems

that now reside within industrial environments. But we want to combine this with process specific monitoring and analysis so that we can marry a logical view of the environment along with a physics centric or process centric view of just what's going on within the plant environment so that we can ascertain things such as the status of process protection,

process safety, or how different items of the overall process environment are interacting and what our IT visibility may indicate certain entities are trying to do within that environment. But also we want to make sure that we're investing in resilience and recovery. This is always an uncomfortable topic because it implies that bad things have already happened. But if we look at events like the 2016 and 2017 events,

we need to make sure as ICS defenders and ICS operators that we have the capability of not only identifying what changes have taken place within the operating environment, such as the removal of process protection and process safety, but also have a way of ascertaining what those changes were and how to restore or recover from those changes

so that we're not just restoring availability in the sense of bringing processes back online, but also making sure that we're maintaining process integrity and that operations are restored to a known good and known safe state in order to make sure that we're not endangering operations or the personnel within that plant environment. And a key to doing this is making sure

that we're improving visibility into industrial environments. So while we already see process data captured for operations purposes, we have data historians that do this job already, but we need to combine that with improved host and network visibility, much like what we've seen over the past five years in enterprise IT environments to combine data sets to develop a full scope ICS aware visibility

of both the IT and ICS specific aspects of an operating environment to truly understand and track what is going on within the control system environment, both for a defensive perspective, as well as to just understand purely what's going on, should we have a malicious insider or other entity

begin making changes to the environment that could have significant or harmful repercussions. And then finally, we need to make sure that we're including planning for response and resilience. That means adapting or modifying the existing contingency planning that exists from an engineering perspective to incorporate cyber,

not just in the ability to restore operations, but also do you have the tools and the capability to perform root cause analysis to see that a modification or an attempted modification was made to a safety system or the denial of service condition on the super tech protective relay. And this also involves a focus of effort on those critical path nodes that allows us

to better allocate or smartly allocate resources on those sort of crown jewel processes around which the entire operation revolves around so that we make sure that we're taking care of the most important assets in our environment. And as a result of all of this, we should be able to allocate resources in such a fashion to facilitate rapid critical resource restoration

in an incident to not just minimize downtime, but to make sure we're again, restoring to a known good known safe state instead of just blindly bringing operations back up and hoping for the best. Ultimately, we're really looking to try and build out a robust defense in depth where we're covering things certainly at the IT layer,

but also bringing things into a multilayered understanding, visualization and visibility into control system environments to track not just items like opportunistic ransomware or IT wipers, but also getting into process specific targeting and modifications that could lead to far more serious effects and building that all into an industrial focused

and industrial aware security program. So with that, I'm right at time. I believe these slides will be posted somewhere. There's just a selection of resources, both things that I've written, as well as from peers from ESET and FireEye and some of the events that we talked about today.

But if we have some time, I can answer questions. I don't know how big of a cushion we were leaving between talks.

Well, I hope this was interesting. Certainly feel free to reach out to me, email, Twitter, whatever works for you as I'm always happy to discuss this and related items as I think it's quite fascinating, especially as we start looking into the more strategic and operations focused aspects of cyber events

within industrial environments. Certainly is a lot more interesting than some of the things we see in IT environments, I think, but I'm a little biased there. But yeah, I don't know, Bryson, if you've got anything for me or anyone else? No, I think you're good. Thank you.

Stop the share and I will let the program move on. I'll be hanging around within the Discord and elsewhere if anyone has thoughts that came up after the fact, but otherwise I hope everyone enjoys the ICS Villages. I know I always do. Thank you.