 Alright everyone, thank you for coming to our talk. It's named, Extending Zeke for ICS Defense. My name's Norman Lunt. As the slide shows you, I'm a security enthusiast. I love P-Caps. And I love the defense side of this game. Where if I could find you anywhere, we'll get you out. Hey, I'm James Dickinson. And as the slide shows, I'm also a security enthusiast. And much like Norm, I enjoy P-Caps and packets that are placed inside of P-Caps. Alright, so to start us off, we're going to talk about some fundamental definitions in case anybody doesn't know. I'm just going to refer to them by their acronym names and not by their full names as it suits me. So ICS stands for Industrial Control System. PLC is Programmable Logic Controller. HMI for Human Machine Interface. And NSM stands for Network Security Monitoring. Alright, so who cares about ICS data, right? It seems in the NSM world, ICS is just an afterthought. Nobody cares, gives a good dog-gone about what's happening on Modbus or what's happening on DMP3 or what's happening with all your Siemens PLCs. So what happens is I downloaded the most recent version of Zeke and I built it from source. And I discovered that had three out of 72 out of the box analyzers were for ICS. And then went online, I poked around, and the Survey of Security Tools for the Industrial Control System Environment said, the survey identified tools such as Bro, which is what Zeke used to be called, Snort and Yara, which are by design highly extensible. Enough so that with minor development, they could be used as ICS solutions for which there's no current tool set. So every year, more and more devices are exposed to attack. And the people who want ICS in their systems, a lot of times they don't care about security because they haven't been hacked or they haven't got to a point where they need security. And so they'll be advised to say, hey, you know what? If we expose this to the internet, we're probably going to get in trouble. And they're like, I don't care. It's not affecting my bottom dollar yet. Just push it. Just push it. Just push it. And so from securityweek.com, this is a report from 2017. They used Shodan, Census, and Google search engines. And they identified over 170,000 ICS components accessible from the web. And it was a 10% growth from 2016 to 2017. I don't know what it is currently, but I don't think it got less. I don't think they're like, you know what? We better not put more ICS stuff out there because, you know, just in case. So why this is really relevant is programming logic controllers or ICS systems in general aren't fault tolerance. Like if at any point you send your data out of order or a mouthform packet or something just doesn't hit right, it just crashes. And sometimes it crashes in a state that's unrecoverable. Unrecoverable in a sense that you can't do it remotely, where somebody has to physically drive out there and power cycle it, or physically go out there and replace it because it's broke so hard. And so why this, so hints is also what happened. I was talking to a guy, this is the whole reason we have this talk, and he was a fellow security researcher, and he said, he said, you have ICS data on your network. And I told him, no I don't. He says, you do, go find it. And so after he and I left this conference, I went back and I found this ICS data. I found these attacks coming in, and I didn't have a convenient way to figure out what was happening with them. I saw the data. I could see the raw bytes, but I didn't know what they meant, I didn't know what they were doing. And I thought, this is probably a problem for everybody. Like, how do I explain to my customer, hey, you know what, you, you know, foreign IP try to hit you 400,000 times to turn off your PLC. I mean, none of them were successful, of course, but it doesn't stop the attacks. So I would like to turn my time over for James to explain to you the Purdue model, and how Zeke works. Yeah, so the Purdue model's been around for a while, in 1978-ish, I think, and really what it is, is just a way to describe how these ICS systems tie into the business network. So if you look at this, you can see down here at level zero, you have the physical devices that are actuating physical processes. So these are things like pumps, sensors, belts, things like that. And then level one here, you have the control devices that are controlling those physical processes. And then as you work your way up the network, you get up to the business analytics portions that are consuming this data to be used for making business decisions and risk decisions, right? And so what we're talking about is defense, right, of the network. And so what we wanna look at is the basic stuff that you do with any network, figuring out where to do segmentation and where to create those security boundaries to isolate that data and protect it, right? And so if you look here, we have some notional firewalls that are in this diagram, right? And so those are some good places to place spans or taps or what have you, however you're gonna monitor this network to capture that data and see what is going on. So why did we choose Zeke as opposed to some other tool for using to monitor and defend ICS data? A couple reasons, Zeke is open source, so that means it's freely available for anyone to use and it has a very active development community. It's also very well documented. There's tons of white papers, talks and whatnot to go look at. Additionally, Zeke comes with a turn complete scripting language. The Zeke scripting language is event driven and it's purpose built for network communications. So it's a great tool for building additional detections on top of and other and tying it into your other systems. Additionally, it has the ability to create custom parsers. So that's what we're talking about today. So you can go into Zeke and modify it for your purposes and build a parser to monitor the protocols that you care about. Additionally, Zeke is fully accessible because of the scripting language and all the other stuff and all the other tools the community has built. It's very easy to plug into your existing network and get those logs into your SIM or to do some sort of active defense with. So creating parsers, we sort of took two approaches here, right? You need to write your own or you can find someone else's and we sort of did both. So the protocol we chose to write our own on is Ethernet IP and SIP. Ethernet IP is the session layer particle for SIP which is the Common Industrial Protocol. Additionally, we went around and tried to find what other tools and things people had done and this researcher, Dane Woolen, wrote a seven protocol that we also used. I should say S7 is the protocol that's used for Simmons PLCs. So creating a Zeke parser. So we aren't gonna dive into the deep, integrated details but we'll cover it over sort of a high level overview. So first thing you need to do is go grab Zeke, right? So you can go to GitHub, find Zeke and just get clone that sucker and you'll have it there. Additionally, other things you wanna do Vlad, who's a member of the Zeke developer community has this bin pack quick start script. It's just a Python script. What that will do for you is it'll create the boilerplate files and code that you need to get started writing a protocol. And then after that, you need to write a protocol. Zeke protocols are written in a high level language called bin pack and so bin pack is purpose built for describing protocols. And so you're just gonna describe the structures in the protocol and then you're gonna tie that into the vents and at a high level, that's what's going on. And then after that, you're gonna run it and it's probably not gonna work and you're just gonna keep iterating. So this is what bin pack looks like. So you can see here we have a couple different things going on. So this top level structure here is the Ethernet IP header that the two protocols we just mentioned use. And we are describing the different values and where they lie in that structure. So for instance, it has a command value that will tell that it describes what the command is that is coming across the wire. And then the length variable just says, hey, expect this much data in the SIP PDU that's to follow. And then so on and so forth. And then right below that, we have a case statement and the case statement is just saying whether the data is from the originator or the responder. And so in this case, and then it's just passing into another data structure here, either Ethernet IP request or Ethernet IP response. And then finally, down here at the bottom, we have the Ethernet IP request. And here we're calling another case statement for the command value that's up in the Ethernet IP header. And so we're just looking at what value is in there to identify what the command is and then passing that along further into the protocol structure. So in a nutshell, that's how BendPak works. There's a little bit more with it in terms of then getting those events into the script player, but that's our quick five-minute intro to BendPak. All right, so I'm gonna cover what we did with that data. The, so off of, what's that thing? That, oh, so off of eBay years ago, James bought a Siemens PLC and we're like, hey, let's blow this thing up, see what happens. And so as far as the S7 protocol parser goes, I took a good hand to it for about 35 hours and then realized somebody else had done all the work and felt dumb and loaded up and it worked great. So first thing we did, so after that when we decided, hey, let's break into this thing and blow it up, the, it didn't have an IP and we couldn't figure out how to give it an IP. So eventually we landed on the Siemens software portal, at one point Siemens had sent us an email saying they couldn't verify we were American and they wouldn't let us download any of their software. We finally got this one called the TIA portal and we set the IP on the PLC and it seems like this one liner, like download the software, set the IP, right? Like, but this is like 30 hours into our project. The next thing I found is there was a, this guy, DarkLBP, it doesn't, I don't know any more data than that from his GitHub. He created this thing called ICS-Sploit. It's a creative use escapee in Python to create custom attacks on PLCs and it already has pre-built attacks for S7. So that worked fantastic and he calls it ICS-Sploit because it has a meta-sploit style interface but it's good if you just wanna, you know, if you wanna blow up your own PLCs from eBay. Then I started Wireshark, I captured data off my Nick, then I ran the attacks and then I took that data, fed it into Zeke that was running our S7 parser and we produced Zeke logs. So what this is is this is ICS-Sploit giving me data back, right? So this is a scanning style attack and you can tell it what rack and what slot, et cetera and it said it found these two vulnerable spots, slot zero and slot one. The IP we set for our Siemens PLC was 192.168.38.200. So this is what, as an attacker you say, oh look, there's some stuff, I got some data. So this is, say, here's where I launched my attacks. This order code on there will give, if you go and search it, it gives you insight about what type of PLC it is. And this is what Zeke looks like. There's three types of logs represented here. The con log, which is your connection log, your S7 setup, communication log and on the bottom your S7 user data log. Now the first field there is your UID and Zeke is really important because your UID ties all your different logs together. And so all the blue logs go with blue logs and yellow logs go with yellow logs and if they aren't highlighted it's because they were scanned and nothing returned. So you can see in the column just before it says SRSTR, everywhere where it has a zero it means there was zero bytes returned, which so it got no return. So on my big scan, those are the ones that didn't return which is why they're not highlighted. They're included just to say, hey, I scanned more than just that one area. So in the S7 setup con log, it shows you there was a call for a job, the job was acknowledged and then the user data, it sends these SLS, SZL request and response. And one of the things about Siemens PLC is, it doesn't matter what kind of protection you have on them, you can still read, you can send read requests to the SZL and it'll respond to you every time. You may not be able to do any much more after that but at least you know that you have a live target. The next thing I did is we tried to turn it on and off. So as you can see here, the command description, one to start the PLC or two to stop the PLC. So I set the slot to one because that's the slot that was vulnerable. I set the command to one and then I ran it. And then as you can see, running module, target is alive, sending packet to target, start PLC. So me as the attacker say, oh cool, the PLC started. And then I changed the command to stop it and this is, oh okay, the PLC stopped now. Now, turning on and off, right? It doesn't seem like a major attack, right? You turn the PLC, you turn it on, you turn it off, big whoop. So a couple years ago, one of the national labs had this giant generator, just like, I don't know, like a billion kilowatts, it's not that high. I don't know how much it was, it was a giant, it was large. And they turned it on and off rapidly, bump, bump, bump, and it blew up because they started it and stopped it and started it and stopped it and it blew the heck up. And so, so maybe not a catastrophic explosion to kill everybody in the plant, but it's significant enough to require, who knows, the amount of downtime to get the heavy equipment in there to replace that generator. And, and besides like, anytime your PLC just take rogue, wild turn on and off statements, like it's ridiculous, it should never happen. Here's what we have, I split it up in two parts. The top part I call turn on and the top bottom part I call turn off. And again, it's the same, the first two logs are the same. Your con log, which is your connection log, then your setup communication, and then the bottom one that's new for this type of log source is your PLC function. So, main thing in your connection log, data was, was processed, it went, you got bytes to and from. Then you have the job and the job is acknowledged in the setup, in the, yeah, the setup communication. And the last part, it calls this program called P program and it says empty because we didn't actually have a program in there. We did, but it, we deleted it out. Our PLC wasn't connected to anything during this, during this setup, we, I was just happy that we could turn it on and turn it off. And the turn off is the exact same, there's data in the connection log, we have the communication, there's a job, we acknowledge the job, and then it stopped. PLC stopped and so, so how this is relevant to an analyst is rather than just seeing raw data on the wire, just bits that they're trying to figure out, like, if it was UDP and, like DNS, if I give an analyst raw DNS, they could probably tell me what the IP it came from, what the IP requested it, what the IP was returned, because they know that, they live in that space. The TCP IP stack is, is daily stuff, right? But if I say, hey, here's some raw bytes from a PLC turn off command for an S7 protocol. And the analyst is like, yeah, that's cool, bro. You know, I hope it's not broke. Generally, right, in general, like, cause we're not a PLC shop, but maybe if you have a PLC shop, you have guys dedicated just to Siemens PLCs and just to Alan Bradley PLCs and just only guys who study Modbus, right? Does anybody, is that the thing? It is? No, no, no, where you have a Modbus guy on the network analyzing only Modbus data, and he's like, So, so that's what we had. Those are attacks we ran. We scan and we turned it off. And I will now turn the time over to James for our conclusion. So, we're blue team guys right through and through. We enjoy finding bad guys. We enjoy seeing them attack our networks and then no routing their stuff. That's, that's what we do, right? So, I think from our perspective, we think this stuff's really cool. We hope you guys think it's cool too. We encourage you, if you think it's cool, to go look at Zeke, maybe contribute, write some parsers of your own. And then additionally, if you have guys have novel detections you can think of, Zeke's a great tool to build detections in and I think that's all we have. Yeah, are there any questions? Does anybody care to know more about my PCAP? All right, thank you guys. Thanks.