 Good afternoon. It's my pleasure to introduce Joe Slowick who's going to give us a fascinating talk on the anatomy of ICS disruptive attacks. Please give him a warm welcome to Joe. Thank you. Were you good for AV? Got the thumbs up? All right. So first off I got a little bit of, you know, what my name is or whatever, but who's this guy up on stage? Well, my name's Joe Slowick. I have done threat intelligence incident response and some other things. Currently I work for a company called Dregos based in Maryland, although I am based in New Mexico. It's an industrial control system focused security company where I do adversary hunting which is just a cute way of saying that I do threat intelligence work. Before that I was running incident response operations at Los Alamos National Laboratory. That's why I still live in New Mexico because I still stay in town. Just kind of hang out and bum around and see if they let me into the nuclear weapons laboratory because that's what one does. Before that I was an information warfare officer in the Navy for about five, six years and way back before that, I was actually a philosophy graduate student that dropped out because that seemed like a really stupid idea. So really as you look at this background, you know, I am an unrepentant, you know, just a defender to the core, but past government service I am now doing this on my own terms just as Mr. Captain America has moved on in his own little career arc. So our agenda today is we're going to talk about some of the major ICS disruptive events and orient these along the kill chain. You know, seems like it's a silly idea. I make fun of it a lot, but it's actually really helpful in trying to wrap our arms around how these events play out. But look at two concrete examples from the last couple of years. The crash override event in Ukraine 2015 and the tricest event that took place in Saudi Arabia in 2017. And use this to look at how trade craft within the ICS space has evolved over time. So first, let's break down events. And here's a really busy slide. This is the one you want to take a picture of, I guess, if you're into that sort of thing. You know, really when we're looking at the ICS threat space, we've only got a handful of examples that are out there, at least for the real disruptive bespoke sort of things. In terms of ICS targeting malware, their Stuxnet didn't take us long to get there, did it? We'll come back to that as we move on as well. So I'm not going to talk about that too much here. We had Havix, which was a really interesting piece of software that did some OPC enumeration in order to collect information from devices of interest. Moving on to Black Energy 2, Black Energy Fork that had some specialty tooling for talking with certain human machine interface devices in the ICS environment. And then we get to the things we'll go into a little bit more depth as we move on. Crash override and tricest. And five samples of malware really only have about five or six truly disruptive events of Stuxnet again. All right, moving on. 2014 German steel mill attack. That's a funny one because no one still has a really good idea what the hell happened there. All we know is that a steel mill in Germany ate itself and according to BSI, the German domestic security and intelligence service that they say malware is to blame and full stop, that's it. So if you know anything about that, please let me know because there's not a whole lot that's publicly available right now. Then we start getting into Ukraine, getting manipulated multiple times. So we had 2015 Ukraine with Black Energy 3 just used as a remote access tool in order to then manually deliver a impact by like literally dude BNC DIN and started manipulating controls on the engineering workstation. 2016 got a little more sophisticated with crash override. And then 2017 we had the tricest event which was infecting a safety system, which you want to talk about a dick move. That is a dick move. We'll get into why that's a dick move in a little bit. And so looking at this, you know, yeah, we have some events and then only three really were disruptive events that were fueled by malware. So we're seeing that attacks are kind of rare. Why do we always tell ICS is the new hotness or whatever that the Russians are in the grid and whatnot. Well, we do see an awful lot of probing and reconnaissance activity, you know, going back to Dragonfly, which was deploying the Havix malware in 2013 to 2014 and then moving into a lot of electric utility probing we've seen from about 2015 to the present, including some things that we've disclosed as a company going into 2018. So there's certainly a lot of people operating in this space, but thankfully not gone something. Not too many people that are turning off the lights are causing things to explode. Having said that, though, there's an awful lot of bullshit out there. So even if you were just checking Twitter and what not the other day when there was the event in Massachusetts with, you know, 60 some odd natural gas related fires, you had this joker out there saying like, oh, Russian cyber attack with weaponized Stuxnet. I don't know what the hell that means. But it's not the first time. You go back to 2008 with the turkey saiyan pipeline, had an explosion, malware to blame, no evidence whatsoever since disproven, along with other things. So there's a lot of noise in this space that makes it hard to actually extract signal from it and muddies the waters to understand how these attacks occur and how to defend against them or execute them yourself if you're an asshole. So looking at ICS attack insights, disruptive malware is thankfully rather rare probing and such is increasing. But one thing that's important as you look at these attacks is they're often fairly narrowly tailored to the environment in question. So that means that direct replays of attacks are very unlikely. So we seem Stuxnet, you know, I keep saying it, like if we're redoing shots for this, I'd be almost halfway lit up by now. But Stuxnet to its credit was very well designed in the sense that while it spread further than it probably wanted to, it was only designed to take an effect when I encounter the appropriate type of Siemens step seven programmable logic controller that just have to be used in a nuclear enrichment facility of interest. Crash override was a little modular in nature. But even then it was tailored to a power plant electric well, an electric distribution environment for manipulating electric power distribution in the target environment. And trices was very specifically designed towards the exact piece of equipment it was deployed against. So none of these, can you just simply take them and deploy it somewhere else and expect something to happen unless it happens to be the exact same environment that was originally targeted. You got a lot of work to do in order to make sure that these things could be useful anywhere else. So in looking at this, you know, how does this relate then to the overall attack life cycle? Well, the thing is, is that when we start looking at these sorts of attacks, the things that tend to garner the most attention is that very last stage. So, you know, looking at the ICS cyber kill chain, you know, first off, I sort of detest the use of kill chains, there's miter kill chain or not miter, Mandiant kill chain, Lockie Barton kill chain, block chain, two chains, all sorts of chains. You know, it gets a little confusing after a while, but by orienting how these attacks play out across just the multiple steps involved. I mean, do we have pentesters in the room? Or any sort of, you know, pseudo black hats? Okay, tough crowd. But anyway, you know, executing some sort of an attack isn't just simply run something and walk away. There's many steps involved. The problem in looking at how attacks play out in the industrial space is that you have two distinct phases that play out your initial access into the enterprise IT environment, followed up by a way of pivoting into your actual industrial control environment. And unfortunately, whether as a result of just its sexier to talk about, or it's easier for us to focus on, much attention gets paid to the very end of this entire event, that execution of an ICS disruptive attack, which is fair because that's the most exciting stuff. But it ignores that for this to be successful unless you walk into the environment and log on to the device, you know, physical access or something along those lines, you need to do all of this in order to be successful to even get there in the first place. So if we really want to understand the anatomy of an ICS attack, focusing just on this last stage means you miss an awful lot of necessary context for how to get into these environments, figure out what's going on, be able to deliver some sort of an impact on target, and then actually get it in there and execute it. So this extent expanded you via a kill chain like approach really gives you the opportunity that since there's so few events in question for us to analyze, whether as attack emulation or from a defender perspective, you know, what do you learn from stuck stent like, well, if you're trying to target Siemens step seven PLCs, probably quite a bit. Otherwise, it's a notional attack vector unless you look at how it was able to breach into the environment, spread to where it needed to go into a theoretically air gap environment and then do bad things. So expanding our view to what were those enabling factors really starts to shed light on a lot more factors that are common among different target networks that allow us to start building up an understanding of how do you break into these networks? What information do you need to gather? What capabilities do you need to deploy? And that yields information that is a value. So having said that as background, what let's talk about some events. So crash override occurred late 2016. I made an error earlier in saying 2015 17 December Ukraine for the second year in a row had a bad day right in the middle of winter. Not a nice time to lose power if you're Ukrainian national. But just before midnight, there was a substation in the Greater Kiev area that ended up getting de-energized, resulted in a service shutdown. Now, thankfully, they had some manual control over the service yard in question. So they were able to recover operations pretty damn quick, even though there was some nastiness in what the root cause of this was. Happened to be malware. Might not be the case if that happened in the U.S., though, or other places where we're really used to having a lot of remote access and remote management of this sort of equipment. So there's a lot of initial analysis on this, including by myself and my company. So we had ESET, you know, Indistroyer, us crash override, long story, we can talk about it in the bar afterwards. We co-present it at Black Hat in 2017. That's Robert Lepofsky right there from ESET. So it sounds like, well, this was covered into the ground. Wasn't it got a Black Hat discussion on this? What else could be said? Well, the thing is there was actually quite a lot to learn from this event and not a lot that was discussed that really goes into that whole of kill chain approach I mentioned earlier. So while it was seemingly well documented and well publicized, there were a lot of critical questions that just weren't even addressed or left unanswered, such as how is the ICS network even penetrated in the first place? A non-trivial step. What were the actual capabilities of the malware beyond it was able to turn the lights off? Or in this case, open breakers that control electric distribution. And how do we then take all that information to start building up a layer defense against, not crash override per se, but against crash override-like attacks that take advantage of what that infiltration all the way in route to execution looked like? So if you look at this as an event in question, it's not just a bolt from the blue, but rather a culmination of events beginning with the initial penetration of your ICS network, establishing a foothold within that network, enumerating systems and protocols and delivering an attack. All of that takes time. It doesn't just happen or if it does, you have a very badly run environment. So in looking at crash override in context, you had a lot of prepositioning that was necessary in order to pull this off. Additionally, depending upon what sort of information you have in the target environment to begin with, maybe you're lucky you were able to harvest a lot of spreadsheets or documentation from the Enterprise IT network or do some searching around on the open internet to figure out what gear is operating in the environment. But chances are you're going to need to do some network and protocol enumeration as well to see just what sort of equipment you're targeting. So we're not talking days, probably not even talking weeks. I have a white paper that will be coming out on this in detail in another month, but it really looks like months in terms of development, reconnaissance time, and then attack deployment. So really, you need to develop those access points to get into the network, some means of moving around laterally, and then developing and deploying a capability to deliver that disruptive effect that grabs all the attention. So in looking at this, based upon some data that we were able to gather through somewhat interesting sources, what sort of tools were involved beyond the headline crash override malware framework? Well, a lot of things that look a lot like pentester 101, sans 560, take your choice or whatever thing of class or training going on. We had MemeCats, both just pull the MemeCats source code off of GitHub, compile it, one version, and then do the same thing with packet with UPX. That's it. So not a whole lot of sophistication there, not even trying to hide. PS exec used, although an older version, which is of interest, because that was several versions older at the time of the attack than it needed to be, which indicates that someone was using a tool repo of some sort that was not being very well maintained. And then a lot of scripts, and I'll have some examples or whatever used for things like file transfer, service execution timing, service scheduling, and there were a few custom items. There was a port scanner, like NMAP exists, why would you rewrite NMAP? It still gets picked up by AV too, so I don't know. There was also a backdoor that took up a lot of attention in the initial analysis, including by us because we didn't have a lot of context last year when we were looking at this, but what was interesting when we started looking into the event in light of the additional data we were able to gather on the attack itself, there was something interesting about what was deemed to be the backdoor that allowed crash override to take place. So while you can see from file metadata that they wiped timestamps, January 1, 1970, okay, pretty standard, they didn't clean up everything completely and there were actually artifacts left in the binary when we started doing analysis that showed, there were some time zone chicanery going on here. This was compiled and deployed right before the attack took place, so everything that kind of got rolled up as being the crash override attack framework didn't really come into play until hours before the attack was executed. All those other tools that I mentioned, which are not all that sophisticated tools, were really the driving factors behind how this intrusion took place leading up to the actual disruptive event. So for example, this looks like something you would find on TechNet or some other like Stack Overflow like resource for just moving files around through some scripting. There's no obfuscation here, you know, read in username and password and whatnot, again credential harvesting and reuse was vital to how this attack played out because it really underpinned all the actions in the environment, whether running locally as root or as admin or being able to move laterally through the network by just doing things like mounting shares and copying files using scripts such as this. So yeah, pretty plain as day, looks almost like a legitimate sysadmin tool but used in the case of crash override to start moving the attack payloads through the network. A little more snarky, a little PowerShell, this was not de-obfuscated and presented, this is exactly how it appeared in the environment as far as we can tell. Not even trying to hide here, doing a pull for a MS update resource direct from an IP. It is proxy aware, so okay, someone was trying a little hard but not even trying to do any sort of base 64 encoding or obfuscation and whatnot. So pretty plain as day, if you have PowerShell visibility you're going to catch this. It's not a whole lot of industrial environments I'm aware of that have very good visibility into PowerShell execution though. So know your environment and know what its limitations are when designing your attack. And then for scheduling the final attack itself, well just use a script to schedule remote services and in this case, this is the syntax for executing the crash override framework since it involves multiple inputs. You know, take the initialization or the launcher file, pass to it what the payload package will be which is specific to each ICS impact, feed it a configuration file, set it as an auto start service and the executable itself has a timer in it to tell it when to load up and start doing things like opening breakers and turning off the power. And again, like nothing here is really seeing all that complex and certainly not all that obfuscated. If you know, you know, a little background of what happened it's pretty clear what's going on here. You know, this leads up to the iChart which I should have designed a little bit better if I was doing these slides over into what the crash override framework itself does. As I said before, it's modular in nature as we discovered it and as it was executed in the environment. You had a single launcher, asterisk there, there was one variant. I won't go into that in too much detail here. That launches or is capable of executing four different payloads for different communication schema for running an electric distribution environment. The idea behind that is target multiple devices that are managing the flow of electricity to open breakers and those de-energized lines turn off the power. After that happens, a one or two hour timer window opens up and that leads to a wiper or destructive opponent also known as the asshole stage of the attack. So to timeline this out, launchers starts select a payload via the command line. It's another interesting thing with how this and Trices as well as we'll see are laid out is that these aren't standalone binaries that, you know, fire and forget and walk away. Requires command line inputs, proper syntax in order for these things to work, which makes it a pain in the ass for sandboxes in order to figure out that something's going on. Not that they really can identify that these things are malicious to begin with because as a window is executable it doesn't look all that malicious. From an industrial standpoint it's very malicious but depending on what your context is for looking at these you might not notice. But anyway, after that fires off you get execution of the past in payload which determines what industrial protocol it's going to speak to to what controlling gear in the environment. Open up breakers, then pass on to the wiper which again one or two hour time frame depending upon the sample in question. That's deletes files, remaps, system services to null values and then causes a system fault to shut down the controller. Now from a where does this take place so crash override itself is running on a Windows workstation it's Windows malware, duh. But a workstation that then communicates to PLCs that actually control the underlying physical process. So at this stage with the wiper what it's targeting is the ability for the engineers to recover that environment by reloading project files or configuration files for how that gear is set up. So really it's designed as an operator attack by making it more difficult to try and restore the environment. Now I said earlier that they were able to manually recover operations for how this particular generate or distribution substation was set up which won't always be the case depending upon the environment that you're in. And then as a post attack thing there were a couple of things that were left behind. There was a Trojanized version of notepad which was kind of interesting that open up notepad calls out for something that looks like a interpreter listener in order to get access to the system again. And then they tried using a 2015 vulnerability against Siemens super tech devices. It's a denial of service and especially crafted UDP packet and bad things happen. Except the guys who put this together screwed around with the endiness for how they were reading in IP addresses in a static list within the malware itself so everything was right in backwards so it didn't work. So even your advanced state-sponsored attackers don't necessarily get everything right or test everything before they actually deploy in environments that they are targeting. Moving on. You know what are we seeing here? So from an initial intrusion and lateral movement we're seeing a lot of commodities sort of living off the land techniques things that you would expect out of you know a fairly generic penetration testing engagement. But then on final execution hours before the impact gets delivered it's only then that we start seeing the more complex ICS aware custom sort of malware coming into the environment. You can look at this from a number of ways that sort of holding cards close to your vest instead of exposing them early in case this incident gets picked up and then you provide your response team with interesting samples to look at for what they were planning on doing so that minimizes exposure. But it also means that you're not presenting unique items to key off of from a defensive standpoint until you've essentially achieved your impact on target you've turned the power out. So as far as how this works from a preparation standpoint as well as a defensive standpoint you know the adversaries in this question we're very aware of the limitations within the target environment and in most industrial networks in general in terms of visibility especially host visibility but also what requirements exist for remote access and management. Engineers are going to be VPNing or RDP into boxes in order to manage them remotely from whatever control station they sit in to devices out in the field. So instead of using some esoteric exploit or you know really custom command and control protocols capture credentials and RDP throughout the network and blend in with your engineers and thus leveraging common tools in order to facilitate that by capturing credentials and then scripting commands in order to facilitate execution and spread throughout the environment. So the only thing that looks like malware comes in at the final stages and even then it's ICS-specific malware so a lot of your traditional Windows approaches aren't going to really flag this as necessarily malicious suspicious maybe but not malicious and thus the initial intrusion and everything really blends in with a lot of regular system activity because again using what's required just to manage and maintain these networks on a day-to-day basis in order to move about and see the environment for the ultimate attack. All right so we talked about crash override let's talk about Trisys a little bit more recent a little more mysterious in the news for good reasons you know this headline's a little alarmist but you know Trisys is a event that happened at a gas processing plant in Saudi Arabia in August quotes around that of 2017 the infection resulted in a system shutdown but a system shutdown during exploitation so it wasn't necessarily the attack itself that resulted in the shutdown but rather something seemed to have gone wrong that resulted in the targeted safety system to trip now the attack itself was as I indicated earlier it's very narrowly focused on a Schneider electric triconics device a safety instrumented system specifically running the 3008 version running the power pc processor whereas more recent versions use an arm processor so unless you're running this exact piece of equipment with the firmware version 11.3 or 10.3 I should have had that up there Trisys doesn't work for you just not even relevant so very specifically focused on what was in the target environment here so quick background I know I've kind of assumed a lot of ICS knowledge but tried to keep this high level but just for the importance of the significance of this attack you know what's the safety instrumented system or SIS well it's a failsafe for an industrial process to put it very bluntly this is the gear in the environment that acts as a failsafe that if you know the shit starts going sideways it steps in in order to make sure that systems are brought to a known safe state so this is the system designed to make sure that like that German steel mill the facility doesn't eat itself and that people don't get hurt or people don't die targeting a safety system is a pretty serious thing because even if your ultimate goal because you can do a lot with where these sit in the network as a result of compromising it but you're at least tacitly acknowledging that I'm okay if this kills someone if I have an oops as a result of meddling with the safety system so that's why from our perspective at least this is a pretty big frickin deal moving back to Trisys itself how the attack played out is that first needed to get connection to assist connecting workstation you know what's the point of this if you can't actually talk to the device and one point of contention that came up with other researchers is that oh you never have these things networks this is an anomaly like no if you go back 10 years even to vendor documentation by vendors such as Honeywell Yokigawa etc vendor documentation specifies having these devices with at least limited connectivity into the environments in question in order to take advantage of data transfer access to other processes and other controllers in the environment so the idea that you could air gap the problem away is something that hasn't really existed for at least a decade at least in many cases anyway once you get access to something that can talk to your safety system of interest Trisys as a attack package gets transferred to it the EXE uploads a new Tristation product program to the target safety system and then it starts into taking advantage of unmapped controller functions ways of interacting with it remotely and add some new bonus ones to allow essentially like root get level access to the device in question so pretty sophisticated stuff I'm not the foremost expert on are you in this one but I can put you in touch with someone who is the main thing is that is this was executed something went wrong which led to that shutdown at a certain point where the safety system tripped as a result of this attack progression thus notifying people that hey something's wrong and to the environment's credit not they didn't just like oh well reboot it and hope that things come up correctly they investigated and found that malware is at stake which is not always an obvious step now looking at itself sort of like crash override we're talking about multiple components here so there's a trial log EXE which is compiled Python that reads a bunch of libraries from the oddly enough named library dot zip that includes the communications libraries for how to speak to a Schneider electric triconics device and then when those execute they concatenate to dot bin payloads that get transferred to the safety system to insert that root kit for further access and then after that we don't know what the actual intention was because the attack failed in route to get into that final stage so the adversary built and deployed a root kit for a very specifically designed safety system that is not a trivial feat of software engineering the ultimate purpose of that was unknown there's a lot of different things you can do with that but just like when we were looking at crash override this isn't something that you can just hop into an environment pull up metasploit select a couple of packages exploit a few things and walk away like nope need a lot of specific knowledge about the environment in question the device that was impacted and the access and knowledge necessary in order to gather all those details to put together your attack furthermore when we start looking at that whole of kill chain approach and unfortunately our information isn't quite as good in this respect as I would like it to be we're seeing a combination of items that were used to facilitate this there were some custom executables that were used as tools things like password dumpers that credential theft thing comes up as very important again maybe cat's functionality so dumping else ass memory and then some simple but fairly effective backdoor tools but really driving a lot of this was the same credential capture and replay again taking advantage of the fact that in these environments by necessity engineers are going to need to remotely authenticate to and work with systems just to operate the environment overall you could look at this like well it's not a very sophisticated attack I always call bullshit on that because an attack is only as sophisticated as it needs to be otherwise why bother so in this respect the adversary did just what they needed to in order to get in position to deliver the more custom or more esoteric exploit and thus gain the disruptive effect on the safety system so from a pre-attack standpoint pre-attack being pre the execution of the safety system targeted malware we're really just looking to support and enable that ICS attack penetrate the network establish infiltration and exfiltration routes so that you can move your attack payload in the network and just don't get caught there's evidence that some of this might have been detected by the victim network but because they were kind of using fairly commodity looking tools and not really burning anything very fancy or custom you know if you look at this from especially from an overtaxed incident responder standpoint like oh well we caught a little bit of malware doesn't look all that sophisticated let's move on that's an assumption but it's a fairly safe one in a lot of environments that some of the tools in question may have simply been brushed aside as a minor infection event when really it was part of a much more nasty whole so really this is working as an enabling mission so harvest credential in order to start pivoting through the environment there's indications even that the adversary in this case indicating a level of sophistication was able to likely defeat a multi-factor authentication mechanism that was employed or recently employed in the environment so certainly they were capable of doing some rather fancy things defeating VPN infrastructure and just figuring out ways in order to get into the environment dig in and then get ready to deliver the custom sort of tools so what the attacker avoided in this really aside from the actual tricest payload is the sort of complex malware that we see in association with groups like fancy bearer so like the sednet kit or you know going to apt3 and perp malware or whatever really complex pieces of software that are nice from a defender or a researcher's point of view because it's really easy to build signatures off of them instead you know of avoiding additionally no custom c2 custom encoding schema just again remotely off to the network and hide it in the RDP traffic thus avoiding the sorts of things that you build signatures and detection sets around the result is the adversary just like with crash override blends into the environment avoids a lot of common touch points for defenders and when caught or if caught before that final disruptive phase can look very commodity or uninteresting from a responders or a forensic experts perspective so the result is you get sort of a bifurcated attack so you have a complex exploit and root kit design specifically for one make model and firmware version of a safety system that's a lot of expensive effort on a very narrowly defined target base that provides the capability to manipulate safety logic somewhat undetected and is the precursor to a potential cyber physical event but then enabling all that you have a bunch of sort of again commodity blending in techniques and a lot of use of either off the shelf sort of scripts and other commands a little bit of customization and then otherwise just relying on credential capture and system commands door to get into a place to deliver that actual final payload so how does this actually map to the you know overall and you know looking at the anatomy of these attacks what sort of lessons can we learn for where trade craft is evolving so what we can learn is that initial access and lateral movement your high-end adversaries that are capable of executing something like a tricest event or a crash override event are eschewing custom malware tools they're not using these until absolutely necessary as part of their operations there are no sednits or purpees or I don't know pick something else a ghost is still a thing too I guess but you know anyway the sorts of things that malware analysts build their careers off of instead using things like power shell scripts and just scripting native windows commands to get into the position to deliver the final custom designed ICS attack at that stage we get stuff that is really interesting highly customized that you can build signatures off of but because like in the case of the tricest attack and less so but still to some degree the crash override attack you can build signatures for these sorts of things but they're not very useful because the malware in question is only going to work in a very limited set of environments so a CIS attack against a Honeywell or Yocagala GE or other environment is going to look from a malware level a lot different from the one targeting Schneider electric you could even argue and I will argue that you know aside from doing things like packing your malware not using compiled Python for God's sakes you know something like UPX packing and whatnot trivially easy to try to obey these detections not even going into the actual functional operation of how the malware works so what we see then is a sort of division in effort for how these attacks play out when we map these to the kill chain so your initial access you know all of your run up to that executing an ICS attack looks fairly commodity in nature not a whole lot of custom tools involved a lot of blending in really relying on living off the land and then once we get into the point where we know what we're looking at within the ICS environment what sort of attack needs to be executed then and only then at this final stage of delivering and executing an ICS attack do attackers show their hands so to speak and deliver something that really looks like simple but really is sophisticated narrowly tailored malware designed to disrupt industrial processes part of this and this goes into some bigger points is that you know this living off the land scripting etc really represents a simplification of operations and that you can facilitate development you maybe minimize specialist skills a lot would argue that knowing what tools and when to use them is actually a very advanced skill set for more to make sure that you're evading detection and not leaving that much in the way of a footprint on the environment but we can discuss that later and it makes it harder at these initial stages to break out an intrusion as quote unquote advanced overall represents a simplification of TTPs if only from the standpoint of being able to do things like develop YARA for these or develop a snort signature against a custom C2 profile none of that exists so unless you're really doing in-depth host monitoring and mapping logins and looking for anomalies there and what not it gets very hard to see how these attacks are being executed at early stages so the things that are really driving this process credential theft keeps coming up keeps coming up to this day for things like the grid probing we've seen in the U.S. and the United Kingdom we see theft via phishing via leaking there was an interesting redirect or inserting a little reference to a file object within web pages or documents that then prompts an external SMB connection and harvesting credentials from that as well as dumping within the environment through vimecats or other tools key loggers etc but once harvested it allows adversaries to take advantage of the natural environment operational environment within industrial networks of remote access remote authentication remote administration to blend in with regular engineer traffic multi-factor can help but try system the case that that might not be the thing that really it's not the silver bullet so to speak it's better than nothing don't get me wrong MFA all the things but doesn't necessarily Hello block everything supplementing that or then following the ability to harvest credentials living off the land so I'm able to log on as administrator remotely access a system with elevated privileges now I can use PowerShell WMI CMD take your pick to do whatever I want in the system such as create backdoor accounts it changed firewall rules to allow for remote access from other machines enumerate the system transfer and execute files including remotely if I have PS exec at my disposal and as a result you're evading AV detection maybe you're learning on PS exec but if depending on your environment that might not be such a good thing but also simplifies development and deployment because I don't need to bring in tools with me because all my tools are already waiting for me once I get into the environment that also means I've reduced a touch point that you know presumably files are being analyzed as they're brought in from enterprise IT into a segregated industrial network now that I'm not necessarily bringing tools over though I don't have that as a potential detection point furthermore you're really blending in with system and network operations at the ICS level we're seeing a different trend with increasing complexity in that specialist knowledge like for example from 2015 to 2016 Ukraine 2015 Ukraine someone just remotely accessed the engineering work station you can see video on YouTube of the mouse moving while the operator films with the cell phone and opening breakers manually crash override automates that process by writing malware to manipulate the control gear in question so what you're doing is codifying the specialist knowledge required to manipulate the industrial system and software what that means is that the person who is delivering the attack they just don't need to know a damn thing about industrial processes nor deliver the effect because they're supporting development team codified all that expert knowledge and the software they run they just need to get in position in order to execute it in the right spot so we've seen this in the crash override attack modules so the different ways the communication are structured for each of the payload modules in effect as well as in the trices root kit by providing the means of you know how to communicate using the tristation protocol what the function codes were that needed to be overwritten or rather enabled that were not enabled by default etc so what we see as we move over time is a transition in capabilities you know avoiding stucks that in this case because I'm going to get to that in a second for how that fits in you know we had Havex which was you know had a native ICS capability again that ability to query OPC but very manual in terms of you know an operator runs it on a host in order to extract information black energy too is kind of the same thing allows some capabilities against the human machine interface HMI device but still operator run Ukraine 2015 is almost a regression in that really it's just using credential compromise for everything installing the black energy three backdoor you know rat on target in question and manually manipulating breakers and then we see an increase in again this encoding specialist knowledge in the software itself in crash override in trices so encoding the ICS functionality in each of the payloads that crash override looks to to manipulate switch gear in the case of trices simplifying the way of interacting with the safety instrumented system therefore eliminating the need that the person on keyboard accessing the device needs that specialized knowledge in order to interact with it so the next steps here then is that the overall trend line is towards you know fairly shouldn't say simplistic but certainly malware less ways of initial entry and manipulation of the target environment leading to specialized software designed to manipulate industrial processes the next logical step because you know what do you want to do with any process like I don't want to do things manually every time I want to automate it script it up etc well start automating all these steps including your initial propagation the lateral movement and then introduce some sort of autonomous capability to identify when you're in place in order to deliver your ICS impact of desire and how to execute it in other words recreate Stuxnet so Stuxnet was designed as an autonomous worm it used a couple of zero days in the windows environment for in order to spread and then was aware of when it got into the proper environment in order to then deploy a specific attack against the Siemens PLC devices that were of issue now currently as we're looking at the environment adversaries are still very much reliant on a human in the loop for that an initial infection vector getting into these networks and getting in place to then deploy something that is ICS aware to deliver an effect the next step is doing something like we saw with Stuxnet and automating that targeting and propagation phase because we've already seen successful at least pseudo automation of the actual industrial manipulation part in things like crash override and in Trices so with that we've seen over the last couple of years a return of the worms rise is probably not really relevant because everyone remembers Convicker that's not that long ago actually it is kind of that long ago anyway you know we had Marai Marai was an internet of shit targeting thing using hard coded credentials IOT specific okay not really a big deal but then with WannaCry things start getting really interesting SMB exploit it was IOT focused but there were industrial environments that to this day are still getting hit with WannaCry because you can't patch all the things there and once it gets access and there are a couple of different means where that can happen it spreads like wildfire because SMB one is unfortunately very much used in these environments for semi good reasons but then after we had WannaCry you know get to not patch in bad rabbit and then start combining your SMB v1 exploits with credential capture and reuse on the fly so this started encoding NemeCats functionality into the worm itself so that it could either try the exploit or replay credentials that get harvested as the worm propagates up until Olympic destroyer which although IT focused relied purely on credentials in order for it spread by using a list of hard coded items that were captured during initial access to the target network and then deploying credential capture and replay on the fly to further propagation now considering how many hard coded default vendor default passwords etc exist within industrial environments very similar to IoT so we'll talk IIoT industrial internet of things that sort of attack is very powerful and likely in these environments and I'm kind of surprised we haven't seen one or discovered one yet so we're already seeing autonomous malware emerging that you know does away with trying to find a couple of really you know interesting zero days like Stuxnet used but instead of relying purely on the same sort of techniques that we've seen used interactively to spread within these networks mostly reflected so far in ransomware and disruptive worms the only thing that you really need in order to start weaponizing this in a much more worrying scale is building in that level of environmental awareness and including the proper payload to execute an attack package within a industrial environment so again that sort of Stuxnet like functionality so what's the implications of this tradecraft development as we've seen means that from a security perspective and like I said at the beginning like I am a die hard defender I don't do pen testing or any of that kind of stuff or whatever I want to find this stuff kick it out and or stop it in the first place this sort of development though makes the job harder because the sort of defensive techniques that we've seen popular or at least rise and frequency in enterprise IT environments greater host visibility through things like Sysmon or OS query or other packages the proliferation of so many fancy and very expensive EDR products etc we don't have that industrial environments and a lot of cases you're not going to get those sorts of things because they're either too resource intensive they can block things that shouldn't be blocked resulting in service disruptions etc so you're getting this greater scope of risk that we've seen in enterprise IT for a while but without being able to migrate some of the same tools that defenders have used to try and get ahead of those threats furthermore based upon how this tradecraft has evolved we're simplifying operations for the attackers such that you know going back 10 years or so maybe or even five years for that matter you know your pool of ICS defenders and ICS attackers were both mercifully small almost like you could fit everyone in this whole conference room and just have everyone fight it out and then whoever walks out or whatever or like we win but now as a result of simplifying things such that you're using fairly generic vanilla IT tradecraft to get into and around these networks combined with something that's to pull developed elsewhere the amount of specialized knowledge required to be an attacker is significantly reduced whereas from a defender's standpoint it's still very high so there is a mismatch between offense and defense that is emerging the result is that from a attacker standpoint the scalability of operations the ability to you know enlist or enlist is a loaded word from this space more talent or more bodies as potential attackers supported by one core development team that does your exploit development your effects package development is pretty significant and if you add on further automation in the scary scenario you know creating Stuxnet light not weaponized Stuxnet like that Twitter garbage from the other day I hope everyone has followed that well don't follow that threat it's garbage but anyway the idea of encoding that self propagating worm with ICS environmental awareness will really then significantly tilt the scales against defense such that we're going to have to work a lot harder so that's all I've got that was a lot jammed into a short period of time but I did make sure to leave time for questions I've got a list of further reading and references if you're interested in exploring any of these topics in greater detail it's been a lot of work in this space lately by a lot of great people so you'll see things from like ESETS report for an indistroyer FireEyes work on Trice's Triton all the way down to some of the more historical events we've seen such as with Havocs so with that you know questions comments rotten produce just air gas can you elaborate all that I mean really this is just the case of Stuxnet where depending on how you want to look at it is that you know the introduction of self-propagating malware be a USB that allowed for an air gap to be defeated I would say that the bigger I'm assuming it's a scenario of a USB carrier that can carry the stuff in an air gap right again but basically I'm sorry repeat that last bit how is this a scenario where the USB is being used in the air gap is not just floating yeah yeah nothing really the important point to take from this and you know this is all you'll see uninformed is probably a nasty word for this but they are uninformed pieces about like oh you know why are these things networked in the first place like I tell you what that ship sailed many many years ago and we're not going back there outside of nuclear power where there are legal ramifications to connecting these networks you don't see an actual air gap outside of well even then like maybe classified networks nuclear power and then a few other standalone otherwise the dedicated networks that run your electric power clean make sure you have clean water run manufacturing plants it's connected to the enterprise environment if nothing else like for example with WannaCry how do you get WannaCry on a factory floor in fact I should I have a slide that shows it on a HMI within an automotive plant it's really quite simple so data historians aggregate data within the industrial environment to monitor processes and keep track of things a lot of times we'll have connections to various business intelligence services on the enterprise side got to get data transferred between those two and so you have a built-in tunnel that just so happens to be using SMB that's bridging these environments allowing the woman to propagate now one of the things that we recommended from that is that doesn't need to be a bi-directional tunnel you should try to apply these things safely and any any is not a good firewall rule in almost any case whatsoever but yeah the idea that there are air gaps or the possibility of introducing air gaps is something that modern industrial network design and efficiencies just simply doesn't allow anymore at the last stage that it's at the last minute what about the initial stage is it possible that even though there were only a few plants that we know of there are a lot of systems that are deep-fragged yep that is an excellent question and that's hard because this is where looking at tradecraft you know for example something starts out with a fishing campaign well I could fish all the damn time how do I identify the fishing campaign that's leading to a future industrial impact versus the one that's just trying to you know mine cryptocurrency or steal trade secrets or whatnot you know the guidance that I have I give there the ways of trying to suss those out is you know building not just awareness of threats within the industrial environment but starting to think you know the sort of purple teaming exercise of well as an attacker what sort of things would I need to do on that initial access vector to make possible those stage two effects so if I see a fishing campaign like well did all my process engineers get the same fish or variants of the same thing if so I might want the IT security team to look a little bit harder at that one even if they all seemingly got blocked then something that seems a little more you know disparate or whatever the same things like looking at some of the reconnaissance activity that was probing the U.S. and U.K. grid infrastructure a lot of that started out as watering hole attacks on various ICS resources of inserting that redirect SMB thing in order to harvest credentials and transfer from there so being able to identify like well not just that oh I'm leaking credentials why but oh wait a minute this actually represents a targeting profile based upon who my likely users are and that's what we're trying to emphasize is you know detect and mitigate these things earlier because you know while it's more interesting and you're more likely to get a black cat talk when you'd find and discover that you know stage two disruptive attack or whatever and like look at what we found I'm perfectly happy to kill all this stuff and shoot it in the face right here and avoiding trying to respond and remediate at that stage it's hard but it's kind of where we need to be okay anything else I'll be around no you can make fun of me later if you want okay true why not now all right well thanks everyone