 Thanks for coming out for a nice and cool DEFCON, right? It's so nice outside. But to kick things off right away, who am I? So I'm Joe Sloick. What do I do? Currently, I work for Intelligence for Dregos, an industrial control system focused cybersecurity company in case you haven't heard of it. Prior to that though, I was running Incident Response at Los Alamos National Laboratory, was in the Navy, did some things there. Some were interesting, some were not. And I was actually a philosophy graduate student dropout at the University of Chicago before I got involved in anything relating to computers, like the most I did before maybe the Navy was game. So yeah, kind of took an interesting, well we've all taken interesting paths to this field. But enough about me. Main thing we want to talk about today are, you know, what are some major ICS attacks? What could we learn from those? But also look at those in the context of a surge and sort of minor IT based events and look for the overlap and behaviors between these two and how do we can start designing defense in light of what we've observed from the sort of smaller things that are bubbling up. So looking at ICS events, there's really not all that many that are publicly disclosed or identified. So we've certainly have seen some rather headline grabbing events in the last few years, but you know in terms of ICS focused malware, you have Stuxnet, Drink, Havex, Black Energy 2 and 3, although Black Energy 3 really is an ICS based. It was just used for an ICS attack. We can talk about that after this if you'd like. The crash override framework, which I had the pleasure of being here last year to talk about that with the guys from ESET and then Trisys, which was fairly recent August of last year 2017. But then looking at this, we have a few other disruptive attacks. You know, the malware maps to certain things like we know what happened, what has happened in Ukraine. There was the still mysterious German steel mill event of 2014. If anyone has more info on that, please talk to me. And you know, then moving into again the events I just talked about with Trisys and Crash Override and only a couple of things that have genuinely been disruptive. Stuxnet, Crash Override and Trisys. So we're not talking about a very large sample size. And again, emphasizing known you know, if you happen to be a three letter agency person with little lots of you know, words and letters or whatever after your name, maybe you can speak to some others just not here. But there's just not that many events to start designing detections around and take lessons from. So you know, if we're looking to design defense in ICS environments, what's our corpus of data? What is our ability in order to start reading into this so that we can start building out a defensive framework? Well, we just don't have enough items within the ICS space to really use those as at least our exclusive set of building blocks for how to arrange defense. Furthermore, if you're taking a very traditional IOC approach to defense, you're just going to find yourself in a bad spot quite quickly because we don't have a very large set of IOCs. We have you know, maybe a couple dozen hashes, you know, IP addresses and stuff like that might be somewhat relevant depending on the environment, but we're talking about you know, presumably a controlled network that's not hooked up to the internet, I hope. So instead of focusing on these IOCs, why don't we look at methodologies instead to look at how adversaries fundamentally have to behave and start building out defense in that respect. You know, furthermore, looking at the attacks in question, you know, especially when we're talking about the disruptive things, they're very specific to what they were designed to disrupt. You know, it sucks that if you weren't running a enrichment facility in Central Asia-ish or whatever, you really didn't have to worry about it. It might have spread to your system, but the way it was designed, it was really only looking for a very specific environment to trigger its payload. Crash Override was kind of modular, but at the same time, you really needed to build up the capabilities in question in order to deliver the effect on target. And then Trices was very specific. Like if you're not running the exact piece of equipment with the exact processor set and the exact firmware set that it was built to, you really don't need to worry about it. Very much designed for the target in question. So again, if you're trying to build defense off of these, using the IOCs from Trices is useless, because unless you're running that very specific piece of equipment, which some people may, it's not germane to your interests. It's not relevant to defending your network. So what we've really seen when it comes to, you know, not to cast dispersion on other researchers and whatnot, but when it comes to talks like this or going to Black Hat and other big events, and we look at things across the ICS cyber kill chain, I'm sorry, you know, we really see things focusing on just that final stage that, you know, execute attack. What's that disruptive, destructive event? But we leave out all of these other things. So what we really want to do is because past events aren't all that sufficient to start designing a more robust defensive framework because we want to, you know, look for other ways of going about this to see what it is that we're missing and how we can move forward to build something more robust, especially for a control system environment. So while we've talked about, you know, the scope and scale of ICS events, where do we get this larger corpus of data than to start building stuff up? Well, really, we can just look at general IT infections because, you know, buzzword here, IT OT convergence means that a lot of your classic IT vulnerabilities and threat surface has been migrated into the operational environment. You know, aside from marketing buzz talk around that, you know, from a security perspective, that's pretty damn important because it means that a lot of the lessons and a lot of the things that we're seeing in IT environments get moved into the ICS environment and are just as effective there and perhaps even more so because we're dealing with environments that don't have or are not amenable to the fancy EDR solutions or, you know, complete visibility and host-based logging and whatnot. So that's what are the trends that we're seeing in terms of IT-based attacks? Well, we're seeing the rise again of the worms, you know, for those who are maybe a little, this looks like a good audience, everyone knows what Conficker is, etc., but, you know, really a return to that warmable sort of malware over the last year or so. Really seeing a re-emphasis on credential capture and reuse, use of living off the LAN techniques and running scripts in memory, leveraging native windows and operating system technologies in order to execute attacks. And then the unfortunate continued use of wiper malware either as the end destructive event in question or as a means of cleaning up one's tracks at the end of an infection event. So in terms of worms, you know, want to cry. I don't, Marcus isn't in here because we're not that important, but so want to cry about a year ago, you know, everyone was familiar with that. It was exploit fueled, which meant that, you know, if you're running SMB v1, it wasn't patched, you had a bad day if anything that you had was touching the internet back in June-ish of last year. But what was interesting is that while that is still a problem, you can ask TSMC, the Taiwanese chip manufacturer, who had an issue that they are attributing to want to cry just this past weekend. It's still an issue, but we've seen an evolution in how these worms work when we went to not pet you bad rabbit Olympic destroyer and migrating away from just exploits and instead building in things like mini cats to harvest credentials on the fly and then use those to propagate. So it's relatively low skill in a way. I mean, you have to design the software, but once you've done that and deployed it, it's pretty much fire and forget and let things take their course. So looking at the evolution of worms, I didn't mention this originally because it's, you know, Morai, it's important to worm used hard-coded set of credentials to spread really more internet or shit focused than anything else. So not that big of a deal when it comes to ICS environments. Then we moved to want to cry. We had, you know, the SMB exploit that was pretty nasty and it's still going to be nasty in industrial environments for probably the next 10 years as equipment ages off and gets replaced and whatnot. But then when we started getting into not pet you in bad rabbit, we saw exploits paired with credential capture in order to spread until finally we got to Olympic destroyer, which started out with an initial seed of credentials that were harvested through some preliminary operations and then used on the fly capture and reuse to spread quite effectively through the target network. Now, none of these are industrial focused, which is good, but almost all of them have had impacts in industrial environments because their very nature has allowed them to take advantage of certain network connections and levels of connectivity to spread into areas where we really don't want these things to be. So, you know, we're seeing a movement towards that's exploitless migration by harvesting credentials as mail removes throughout the network, dumping things from LSAS and whatnot and taking advantage of the fact that people still stupidly run as a local administrator all the time and avoiding the use of exploits and such in this facilitating living off the land either in an automated fashion by continuing to build up the capacity and capability of these worms or pending that access over that's gained through a wormable exploit to a human operator so that they can take advantage of what this has been able to, you know, warm its way into the network and spread. That leads us to our next topic, living off the land. So that's a buzzword. I hate it, but, you know, I think I say that and everyone kind of knows what I'm talking about. But if you don't, you know, it's really we're talking about the use of native Windows system commands, some legitimate system administration tools like PS exec, as well as administrator-centric scripting languages, PowerShell WMI. No news to this audience, you know, we know that these things are going on, but that's been a really big shift across, you know, especially our more advanced threat actors of really eschewing malware and going more and more towards trying to blend in with native system activity. Finally, wiper malware. This is like asshole stuff right here. You know, now we're talking about destructive stuff that's designed to wipe or otherwise, you know, render systems unusable, you know, examples being the Shemun attacks, the Sony Pictures event. What else did I list there? Yeah. And Olympic destroyer was also a wiper as well. So I'm having a screen resolution issue, so no worries there. But what we've gotten from looking at this is that, okay, these are certainly not ICS focused sort of attack methodologies, but if we take a step back and instead of focusing on that very last stage of how these attack ICS-centric attacks are executed, what I've just talked about facilitates everything that goes on prior, whether that's your initial intrusion into the IT network to get into the ICS environment, as well as the ability to start moving within ICS to identify your final targets and then deliver that bespoke, whatever, destructive payload. So what we really want to do, you know, the specifics of some of these commodity things aren't relevant. I mean, I'm not a very big IOC fan. I blog about that and then people yell at me on Twitter or whatever. But, you know, I'm very much more focused on, you know, how are these things fundamentally operating? And so looking at those sort of general underlying trends gives us an idea of how the attack landscape is shifting and how adversaries that are operating within the industrial environments that this audience cares about will execute attacks and what defenders need to do to evolve to meet them. So expanding the kill chain not only lets us get a view of, you know, things that we can get a better grasp on, it also gives defenders the opportunity to step in and catch these attacks at an earlier stage. So yes, even if you were able to have a good signature to catch Trisys or Crash Override or Stuxnet, yeah, I mean, but you're catching perhaps the very last stage of a complex attack, so you might just have averted boom or you might have been notified and got an email alert about boom 30 minutes before it actually happens and no one's responded to it yet. That's not terribly useful. Really, what we want to do is try and, you know, move left of boom, sorry, former military, so I can actually say that, I guess, too, but, you know, move further left of boom as much as you can so that you can capture and identify these attacks earlier in that kill chain process, which makes them to facilitate cleaning these things up and mitigating any damage. So really what we're trying to do is, you know, Venn diagrams are awesome, aren't they, but overlapping IT attack trends on what the ICS, you know, threat environment looks like and really try and focus on that juicy center right there for the threat surface. Like, that's really where an adversary is going to be operating, where there's an opportunity to go forth and stop those things, especially, again, at an earlier potential stage, but also catch entire categories of attack instead of worrying about very specific intrusion events. Again, going back to the fact that many of these events in question, then when we look at concrete examples are bespoke in the sense that they're very much tuned to the target environment in question. So in ICS, you know, worms, I think, are a big fricking deal. I don't think enough attention has been paid to us despite the fact that Renault, FedEx, Maersk, TSMC, etc., like lots of companies have had a bad day just from an IT focused worm. Imagine if you take the same capabilities that were leveraged in, you know, not even leveraged, but unintentionally use in ICS environments, pair that with something that's ICS specific in terms of propagation and spread, and do something stucks to it, like in terms of awareness for the environment that the malware is running into at a payload, that's a scary day. I'm glad no one's done that yet. Please don't take this idea and run with it and execute that because that would not be cool. But, you know, really it could be quite effective means of getting into a network, burying in quite quickly before defenders might even know that something's going on, and then detonating something further on. Credential capture is very important as well because, well, one of the biggest reasons, you don't have to use malware. If I can log in as, you know, admin-admin, engineer-engineer, etc., I don't need to exploit anything and that, one, lowers my signature threshold. So even if you're running antivirus in the environment, if I don't have to bring, you know, a piece of malware in to do something, but you can just pivot around through RDP and VPN tunnels, like, okay, that's one less thing to look for. But also allows you to start modeling legitimate activity. You don't have to bring tools into the environment, which is another touch point for defenders. It really makes detection very hard. So again, it's, you know, it's something we need to deal with, but it's very much the reality of the now as far as how these attacks are shaping up, at least in their preliminary stages. Living off the land, again, continues this theme. Don't need to bring tools into the environment. I've got all my toolkit right there with me. Maybe I bring PS exec into the environment so I can do some remote process execution, but otherwise, I've got PowerShell. What else do I need? I can run crap in memory and just copy paste the page 64 script and good to go. You know, really allows adversaries to just get in, stay in, and not really have to do a lot of moving back and forth from adversary controlled infrastructure to the target network. So what I'm trying to get at here is we're really looking to build out what I call behavior based defense, targeting the underlying adversary behaviors, targeting what are necessary adversary touch points. You know, you might say that yes, there are potentially infinite different ways of compiling and, you know, creating malware or whatnot to evade signatures, but at the end of the day, an operator needs to get control over implants or they need to design implants with some sort of logic. They typically want to have some means of staying within a network, some means of persistence, but looking at those requirements then as means of targeting what behaviors are necessary to achieve these things, start avoiding these specific one-off implementations reflected in an indicator and build a more robust detection and monitoring framework. So when we're looking about these things, we want to articulate tactics, techniques and procedures, PTPs, again, I'm a former military, I can say that, and, you know, start identifying those underlying attack trends, map those to the necessary adversary behaviors to execute successfully an attack, and then start building out defensive, you know, responses, detection frameworks and playbooks for response based upon what an adversary just simply has to do in order to be successful moving away from the final stages of that ICS attack kill chain. So things that we could look for, you know, pursue those adversary goals, what is it that the attacker needs to do to achieve things, target those and move on, you know, looking for attackers trying to abuse legitimate commands, etc. These are not easy problems to answer and I'm not up here to sell a blinky box that's going to sit in the rack that tells us and people who do typically are selling a little bit of snake oil, you know, these are difficult things to sort of answer and requires both a commitment on the part of defenders to start building up a profile of what attackers are doing and then building up the visibility to actually be able to track these sorts of things. So what we want to do is, you know, you identify a fundamental behavior, you know, adversaries need command and control. C2 is required, unless you're a horrible piece of malware, but even then you might need some C2 of some sort for a little bit of control over how that worm might interact. So like that fundamental idea of C2 is necessary. Well, how are different ways of implementing that possible? You know, what does DNS tunneling look like? What does a, you know, anomalous, hate that word, HTTP connection coming out of the network look like? Look at those ways, those broad base ways of implementing it and what sort of detections can I build around there? And as far as possible, try to avoid that last stage because you can have near infinite instantiations of each of these more general items in terms of concrete observables. Those will change quite trivially, not as trivially in some cases as possible because people are lazy humans, but, you know, it's really trying to stay at this middle ground here to capture both the fundamental requirements in terms of an attack execution while avoiding the sort of limitations afforded by, you know, focusing at that observable stage. So in implementing a behavior-based approach to ICS defense, we really want to identify those behaviors of interest, try and get an idea of the different means of achieving those behavioral objectives, you know, determine, not a notification, I'm sorry, and then build out means of detecting these things as they move along the line. So for an example with credential theft, credential theft or reuse happens. Well, how does it happen? So there's both the, you know, mini-cats, dumping LSAS memory in order to achieve it. What does that look like? Well, yeah. Host and network visibility are important items in terms of answering this, so like in order to see when these events happen, what sort of visibility, what information telemetry do I need to track it, and then how do I then build out an appropriate security response in order to defeat it? So the thing is, is that do not alert on mini-cats. I mean, maybe, like, you know, if someone wants to compile the source code off of GitHub and they're stupid enough to do that, all right, we're going to learn on that hash to catch the lazy, bottom feeding adversaries, although interesting enough, some advanced ones have done this in environments that I'm familiar with, but really the main idea is to focus on, well, what does mini-cats allow you to do? How do I start looking at that idea, not just of seeing the initial credential dump, but then how that's actually implemented by looking for logon activity that may be of interest, you know, anomalous, suspicious, or definitely malicious, and start designing my defensive framework around that? So to talk about a concrete example of this, let's talk about crash override. Why talk about crash override? Well, because I worked on that a lot, and so I can talk about it to a certain level of detail. It's also a pretty important attack in the ICS space. In this case, the attack took place, you know, they had to penetrate the ICS network, establish some sense of some sort of foothold, survey the environment, get a feel what's going on there, and then deliver the attack. What's that sound like? It sounds like that kill chain thing that we were talking about before, meaning that getting from here to there requires a lot of time, effort, and other work in order to really execute it. So if you're only focusing on this final stage right here, you've just seated your pen testing friends or your nasty black cat actors, all sorts of ground in terms of where they're able to operate, fat and happy without you being able to see it. So building up stuff around here lets you start catching this sort of activity. The crash override event required a lot of prepositioning to execute. And looking at how that prepositioning took place, you know, at least from what we've observed so far and reported mostly privately to this point, what we observed was a lot of credential captured reuse. We observed beamy cats in the environment, not just beamy cats, but like beamy cats dumped off the GitHub repo, packed with UPX and then deployed. That's a pretty easy damn signature actually. And then a lot of use of native system commands and tools in order to then facilitate movement of malware throughout the network. So really mapping on right to those same trends that we identified in terms of more general ICS attacks. So yeah, we saw a packed copy of beamy cats, PS exec 2.11 in terms of what was used in the environment for remote process execution. And then a bunch of scripts that could have been pulled from a TechNet help page or from, you know, Stack Overflow in order to facilitate things like system survey, monitoring, verifying that file is removed and then doing some also remote execution stuff. So we're not talking about anything that's really advanced here and really mapping right on to what we've talked about so far. So for an example, here's an ugly ass script that was used by the adversary Electrum within this environment. On its face, it looks very much like something you'd expect using WMI and W script in order to just do some system profiling if you're trying to get a feel for what's in your environment. You know, what's the so what there, among other things, you know, there's no obfuscation whatsoever going on in here. So from a visibility standpoint, are you actually monitoring for these things as they pop up within your network to the extent possible? The example I like to give it, I've given a talk on this previously a few times is pairing bro for file carving with things like Yara in order to do a deep dive into them. Well, you can search for script files and then look for these sort of administrator commands identifying system profiling to at least identify when these things are moving around, which could be a good touchpoint that something a little shady might be going on in the environment. So we've seen an overlap with some of these same general TTPs we talked about. And believe it or not, I didn't just like sort of shoehorn this in like, you know, it's kind of like came to me in a dream, feel mostly likely about alcohol or something similar that, you know, hey, like, you know, what we're seeing with these general attacks actually kind of maps right on what we observed in the crash override event from soup to nuts. So really looking for, you know, how do we start tracking and identifying these sorts of things to build out some robust defense because at the end of the day, these adversaries are following the same sort of script and playbook that we're seeing the more lower level attacks use. So defense against this, you know, really need to build defenses around what we talked about earlier in terms of it attack trends, you know, credential replay and reuse, how do you identify when that's taking place, how do you identify that living off the land's tech taking place. But once you do that, and I'm sorry, we have a short timeframe here, so we're not going to get too much into the weeds on that. But the result of doing that sort of defensive playbook is that you've now not just built up a defense against how the electron adversary responsible for crash override operates, you've also covered a lot of other attack pathways as well for other adversaries that are going to try and do roughly the same damn thing. So we've actually seen this within the ICS environment looking at some of the events that have taken place over the last yearish give or take. Alanite, which is in the news yet again when DHS decided to rerelease after they rereleased news about the Russians in the US electric grid, a lot of their operations, credential capture and reuse and using a lot of scripts and system commands. Same thing looking at the xenotide adversary responsible for trices or Triton. I don't know who said in a black hat talk on that, if you had access to that talk, but you know, unfortunately, they didn't go into the actual preliminary for the attack. But if you look at how the attack was executed in the environment, again, seeing a lot of the same things, Amy cats using native system tools, maybe a few custom scripts and custom binaries, but overall really mapping on to how we're observing these attacks play out in the IT landscape. So the impact is that once you start covering something like credential theft, not only are you defending against a specific adversary, but you're defending against entire classes of behavior, which means that you get a better opportunity in order to try and identify and defeat multiple different things as a result of that sort of commonality and very fundamental overlap in TTP. Worms are another example. So wormable infections, as I mentioned earlier, are really scary and worry me because I think they can kick our ass in the ICS environment if someone sufficiently weaponizes it and we've seen it before, again, Stuxnet drink. But you know, that ability to move and burrow within a network with no oversight is truly scary because it allows for that unsupervised migration into the network and potential to deploy capability with very little human intervention. And as we've seen with certain ICS impacting but IT focused malware sets, they were quite effective even though they weren't didn't intend to be so. So so far again, the only ICS targeting worm is Stuxnet, but others have had ICS impacts. And so focusing on how those impacts came about and how those might be changed and weaponized in the future gives us a good warning for what we need to start doing now, I would say like six months ago, and we're a shore up against these things. And as any ICS professional can tell you just saying, well, apply the patch for MS 1710, like, well, I can't necessarily do that everywhere unless I want to avoid my warranty or, you know, maybe the vendor doesn't support it yet or I need SMBV one because my historian product acquires it in order to move data around the network, etc. So there's a lot of dependencies here and just saying apply the patch is not a good answer. And yes, and the result of not a good answer is that you get this happening in this environment, which is not a good day. I imagine that the poor process engineer in that facility had, I hope he got a beer after that, if nothing else, because it's a pain to deal with. So we avoided, and far as trends within worms is that we've seen first off the avoidance of exploits as time has moved on. So we started out like Stuxnet is still the crown jewel or whatever, couple of Windows zero days and some other fancy shit, not everyone can do that. Marai, okay, a bunch of hard coded passwords for Internet of shit things, but then seeing the weaponization of MS 1710 very effective, still going to be effective for the future. But then adversaries start getting a little savvier and start doing that integrated credential capture and replay to facilitate propagation. So using native means within the system, like net use commands and doing mapping shares to try and copy itself over and avoiding the use of what looks like obvious malicious code. And finally a shift to wipers at the end. This is the asshole move. So we saw it with not pet you, we saw it again with Olympic destroyer, you know, what's the worm doing, get on target, start doing, you know, mucking with the system and make it unbootable or wipe data because you know deployed ransomware that has no decryption key in an ICS environment. That's a very bad day unless you are backing up all your project files offline, etc. That's going to ruin you very fast and make your network quite untenable to operate. So the risk to ICS is that you get some self propagating malware introduced to the environment, it finds and traverses an IT ICS link that might not sound reasonable. But then like in look at want to cry, take advantage of some SMB links from historians to business process systems in the IT network and boom, you got want to cry in the OT environment. And then if you can just weaponize that by tacking on some sort of ICS specific payload, the step that has not been taken yet, thank goodness, you get a really big problem that crops up. So really what you can do is like stuck stuff for dummies, you know, to think that we kind of like move back to what was the most advanced attack yet no one really seemed to like build off of that a little bit is kind of surprising. Yet that's kind of where we are, if you can start taking these sorts of attack pathways and weaponize them in such a fashion that you're not relying on the exploits and add that ICS component, you get a very robust attack that can result in disruption or even potentially destructive destruction if you have a good enough ICS attack developer. So in building defense, you know, how do we want to do this? Well, what's one of the fundamentals behind how this attack executes? Well, it has to spread. So looking at how things can spread within your network, do you have network choke points? Does your network look like the top of this podium in terms of how flat it is? If it does, then you have a problem because if you get a warmable infection on just that one central node or one of them, it's going to propagate everywhere quite quickly. But if you establish choke points and use those as a means of hard need defense by, you know, building them up as bastion hosts or something along those lines, then you get the ability to stop these sorts of things in their tracks or at least sort of limit the damage by allowing you to filter to a certain specific endpoint and being able to take action there. And then reducing that attack surface so identifying what those ITICS traversing links are, locking those down as much as possible and maybe making sure that they host on the other end of those, you know, whether that's putting in something like a, you know, VPN gateway or some other sort of bastion host and making sure that guy's patched, probably a good idea. Finally, you want to increase visibility within the network with worms might not help too much because it's just going to tell you what happened after the fact, which is actually not trivial, because just being able to say that, hey, we know why this happened is still an important question to answer, but can inform detection, mitigation, and also recovery by being able to track how an attack was actually executed within the environment. So the impact is, is that, well, hopefully you get better architecture. You know, you actually have a segmented network, some sane permissions in place, et cetera, and you've reduced your attack surface to mitigate other attacks and you've narrowed the possibilities for interactive intrusion while you're taking care of that wormable threat. So by focusing in how these things self-propagate, you've now taken care of or at least started to address problems like, you know, RDP use by using captured credentials by a human in the loop, taking advantage of single points of failure in the network in order to start spreading malware willy-nilly within the control system network. So really again, taking advantage of what ideas are afforded by these general IT attack trends to improve ICS-based defense. So in developing defense, you know, really we want to, you know, identify those sort of common commodity sorts of attacks and start building up an idea of how these things look within the environment and then close at the sort of pinnacle with how we were going to start building detections and response around them. And again, the idea being is that once you start getting up here in developing ways of responding and identifying these that you're covering a very broad base of potential attacks based upon the identification of fundamental behaviors that adversaries are taking. So ultimately, and I just got the five minute warning, so we're going to have time for questions, is if you look at how attacks play out, and I know this is a sort of an offensive conference, I'm sorry, I'm like, blue team are all the way that defense really has the advantage when it comes to ICS defense if you're doing this sort of work. Because when you look at how an adversary has to operate, they've got a lot of steps that they have to succeed in order to actually execute with the, there we go, in order to actually execute an IT, an ICS-based attack. They got to get into the IT network, they have to figure out how to move from the IT network to get into the control system network, figure out where the hell they are and what's in that control system network, if they haven't harvested that from a spreadsheet sitting on the IT network, which hopefully they didn't. But even if that step's been accomplished and they already know what they're getting into, you still have to get onto those devices, tunnel into where you can actually start delivering a destructive or destructive payload and deploy it. That's a lot of touch points that as defenders you can use in order to trigger off of what's going on, and thus build out a more robust multi-stage defense. And if you're lucky, you get them here. If nothing else, you just want to make sure that your response isn't when you see smoke coming up from one of the machines on the plant floor. But really by following these steps, I would say that defense legitimately has the advantage in having done maybe things that are more on the attacker side. It's harder than it looks and it's harder than we often make it seem and adopting that approach, again, sorry, defender here, really drives home the point that defense is doable within these environments. So that's all I've got. And now we got a fast question. I don't know. I wish I did. There's still a lot of details around that attack that either are not public or simply unknown for various reasons. So we're still poking at that one and hoping to answer that question some day, but unfortunately I don't have an answer for you right now. Yes, that's a good question. And that's again goes to my scary scenario. So, you know, I've seen some other talks or whatever about like, oh, building an ICS attack is easy or whatever. You just buy some stuff off eBay and firmware or whatever. And boom, you build an exploit. It's not that easy, thank goodness, because again, a lot of the benefit to that is depending on how you're building out an attack and what equipment you're targeting, the unfortunate diversity in vendors, standards and protocols builds in a unintentional layer of security in that something that's going to say attack the DMP three protocol for North American electric operations. It's going to be inapplicable for targeting say IEC 61 850, which well, no, that's a bad example. IEC 104 crash override example, more prevalent in Europe in the Middle East. So it's really depends on like what sort of targets you're looking at, what you're actually identifying and then weaponizing it in that fashion. So it is possible though, like we may well, we didn't really see it. And this will be a talk tomorrow, the Modbus capture capability for VPN filter, like people have kind of implemented something along these lines already. But that's only one example. And that is a allegedly, we'll talk to Mr. DeSantis tomorrow, a, you know, state sponsored sort of activity. So not talking about just any Johnny off the street, executing that attack. So in terms of the possibility of developing that, I mean, again, it's going to take time, effort and resources to build that out, but it's not impossible. And we've already seen someone getting part of the way there with Olympic destroyer, because even just the capability that it offered, which was very window system focused in terms of, oh, what's funny, Olympic destroyer, the wiper function operated very similar to the wiper function and crash override. And that on top of wiping some files that also remap systems in a way to render the system unbootable. So really using the same sort of behavior, again, behavior based defense. But if you ran that in an ICS network and it spreads to Windows machines there, and you can do that by, you know, deploy an implant that sniffs for Modbus traffic on the wire. If it's in a situation where it detects Modbus, I might be in the ICS network. Let me fire the wiper there because I'm going to do more damage. Please don't take that idea. But anyway, and at that point you're wiping HMI's and engineering workstations, which yeah, maybe you haven't caused physical destruction, but you've disabled your plant environment and your engineers can't do their job. So yeah, it's eminently possible. It's just not necessarily the easiest thing to do. I do. You know, that's one thing like everyone wants to bemoan the state of ICS security like all the vendors are shit. The engineers don't want to patch their crop or whatever. Like, no, I think everyone's taking this serious. The problem is, is that you're not like this for the same reason why I want to cry is going to be a problem for the next five, 10 years. Probably is that you just don't like, oh, replace that piece of equipment like that cost a million dollars. Right. Exactly. Which is the issue. So as a result, we get a really long tail, you know, that we're dragging behind us of legacy equipment with its own sort of problems, which is why again, building that, you know, layer defensive model is important because like, yeah, I might have some PLCs or whatever that those are going to be vulnerable to, you know, MS-867 or whatever for the next 20 years. And I'm not ripping them out anytime soon. But I've got these HMI's and EW's that are sitting a little further upstream. I can harden those though to make sure that, you know, that lessens the likelihood that someone will be able to take advantage of the weaker equipment at a lower layer of the Purdue model. No. Yes. No. Unless you're nuclear power, there is no air gap. Sorry. That ship sailed a long time ago. Yeah. I mean, just that's a fact of life. Look at vendor documentation. You want updates? Well, you have to have network connectivity. Sorry. And you know what? We get a lot of efficiencies out of having no air gap in terms of, you know, even something as fundamental, which allowed for one to cry. You know, SM, you know, the way it was implemented was wrong, but the fact that it's there is sort of good. You know, links from data historians to business process servers or systems within the IT network. You know, I like having accurate electric bills or, you know, being able to actually measure my process and whatnot. So yeah, these things are here and here to stay. So the best thing is instead of bemoaning, like, oh my God, if only we could air gap these things, like, eh, pump your brakes, we can't do that. You know, identify that that is no longer the case and how do we actually go about defending it then? All right. It's hot in here. So, yeah. Thanks everyone for showing up.