 Alrighty. Hello, everyone. Thank you, first of all. Thank you, thank you, thank you for coming to listen to this talk. I am very grateful that you were willing to spend some time to tune into this presentation. So this presentation is on attacking ICS devices or industrial control system devices and threat emulation with CONPOD. So admittedly, this talk was intended to be in person, live kind of a real event with a roomful of people. Maybe we could do some cool demonstrations and very fun cyber tricks. But unfortunately, with kind of the state of the world right now, we are doing this remotely and virtually digitally. So unfortunately, I kind of watered down what this talk kind of could have been. With that said, I still wanted to bring it to you and I hope that you do, I don't know, get some good information out of it or find your own good gold nuggets maybe that you could take away. So without further ado, let's dive in. First, I have to go through the obligatory introduction, right? Hello. Hi. My name is John Hammond. As part of my day job, I work with the United States Department of Defense with their cyber training academy. I'm a cyber security instructor and kind of a curriculum developer course architect there. Previously, I was working with the Defense Threat Reduction Agency as a red team cyber operator and a lot of really cool stuff in that regard. But that's just what pays the bills. It's really not what's important and fulfilling in our day to day lives. At night, for fun, the really, really good stuff, what I like to do as part of my passion, some pet projects, I do love to play capture the flag. I think that's really, really important in sharpening your cyber security skills and just learning and continuing to grow and kind of pursue that passion. So not only do I like to play a lot of capture the flag, I do like to host and create and develop my own competitions and events. You might have seen me do some work with maybe verset con, the virtual security conference or noncon or previously some others and hope to do more. I also have a small cheesy growing YouTube channel. I like to showcase a lot of cyber security videos or capture the flag walkthroughs or programming tutorials, etc. So you can find me there if you would like to. Okay, let's talk about the real stuff. Let's talk about this talk. This slide is a kind of a roadmap and outline. This is the agenda for what I would like to bring to you today. So some of the bigger concepts we're going to end up setting up con pot, talking about what con pot actually is, what this kind of tool and utility can do for us. And then we'll go ahead and build out an ICS example or industrial control system example, seeing what we can do with con pot to put together maybe a PLC or an HMI that programmable logic controller or the human machine interface that actually lets us kind of have the bare bone essentials for this ICS example and demonstration. And we're going to generate some OT activity or that operational technology interaction. You know, a lot of times we hear the acronym IT for information technology. And that's really good for software or protocols or things that you might see within a corporate network. But when we get to the conversation of industrial control systems, let's turn that acronym on its head. And let's say OT rather than IT for operational technology. So we're going to be talking a little bit about Modbus, some protocols, etc. And then we'll get into simulating threats, or doing some actual cool attacks and offensive stuff with it. Not only are we talking about the offensive work, I would like to at least start the conversation of defensive procedures as well. At the end of presentation, we'll wrap it up with some links and references if you'd like to get in touch with me. And of course, thank you as always for listening and tuning in. Okay, now let's set the stage. Now that all of that fluff is out of the way, let's talk about doing this thing for real. So I am going to be working on an Ubuntu Linux machine. I include that logo here just so I can say, Hey, I'm going to be working off of a flat vanilla Ubuntu image. And that is kind of my Linux distro of choice. You could probably just as easily spin this up, start this sort of thing in any other Linux distribution that might tickle your fancy, that might be your weapon of choice. That is kind of what I tend to work in. Along with that, a lot of the code, a lot of the stuff, a lot of the programs and software that I end up putting together to work with this sort of thing. Again, I'm typically working in Python. And Python is actually what Kanpot, which we will come to explore and work with is written in. And that makes it very, very handy to kind of extend it, add new things to it, explore it, etc, etc. So that is the trio here. These are the three stages that I'm going to be putting together as kind of the vehicle, the vessel for this talk, Ubuntu Linux, Python as our programming or scripting language, and Kanpot as really the good demonstration of how we're going to be putting together these industrial control systems. Okay, what is Kanpot? You've heard me say this word over and over and over again, but what the heck am I actually talking about when I say that if you aren't familiar with it previously? So this is interesting, right? Kanpot is a server side industrial control systems honeypot. And now you think of honeypot, you oftentimes think of some maybe attractive, deceptive trickery or a trap that attackers might fall into so that you could actually kind of monitor and see, oh, this is the sort of gimmick or gotcha that maybe an adversarial offensive bad guy might go after. And that way you can kind of see what they're doing and how they operate within a network. We're actually going to be using Kanpot, yes, as that ICS or industrial control systems honeypot as a honeypot, right? Because you might want to set this up to see how if it were accessible on the internet, people would try to beat it up or work with it or do things to it, just interacting with that port or working with those protocols. But we're going to be using it just to kind of have mental and abstract playground for working with these industrial control systems and these ICS devices and protocols, et cetera. The wonderful thing about Kanpot is that it is all software based, right? So it's easy to deploy, modify, extend, providing a range of common ICS protocols, and you can build out your own system to emulate complex infrastructure without actually having all of this hardware. So you could pretend to be a power plant without actually having to have to own a power plant, right? Kind of neat. You don't need to have a real water tank or whatever HVAC system or whatever you're trying to put together. You don't need to have that real world physical hardware stuff. We could just kind of emulate all that with just our keyboard and our computer, more of that programming software hacker mindset. So because we're providing complete stacks of the protocols, Kanpot can be accessed with productive HDMI or extended with real hardware. So you don't need to have the giant physical machinery or whatever the case may be. We can work with it on our own. If you want to check it out, you can find it at kanpot.org. But let's dive into it a little bit more. Let's talk about how to install it and get it ready. You can find a GitHub repository, github.com, searching for Kanpot. The work that I had done with Kanpot previously is a little bit before this time in our lives, right? So right now it's 2020. Python 2 is long gone. Python 2 is dead and is meant to be forgotten and abandoned. Admittedly, some of the code and stuff that I've worked with before previously was before that, okay, end of life for Python 2. So some of the stuff that you might see in the slides, forgive me, maybe I don't have my parentheses around my print statements or we're just doing weird things with bytes and strings or I'm decoding things and hacks, whatever the case may be. I don't want to alarm you or make those bells and whistles go off in your heads. That's just, hey, putting that out there. In the installation instructions that you will find for Kanpot now, currently at the time of recording, at the time of this presentation, it's going to be encouraging you to use Python 3, specifically Python 3.6. And they even offer a Docker, if you're into that containerization, kind of like lightweight virtual machine, like containerize everything mentality, you can just pull down Kanpot and work with it as a Docker container, as a Docker image, a Docker instance. But they do recommend and if you take a look at their documentation, check out what they're telling you and advising you to do. They actually do recommend, let's go through this procedure to install the system dependencies. Again, I'm on Ubuntu. So I'm going to be using apt get or aptitude apps to install all the system-wide dependencies. And then with Python, Python 3.6 in this case, I'll go ahead and create a virtual machine that I can kind of keep all the packages necessary for Kanpot in. And because we've cloned this from the repository, hey, we'll go ahead and grab its requirements, pull loads all in with pip, and then we can go ahead and install Kanpot. Okay, at this point, if you had successfully gotten Kanpot installed with just those simple commands, you should be able to run it from the command line just simply Kanpot. And you'll have this nice little ASCII art displayed showcasing your version. So at the time of recording this, it looks like I'm at version 0.6.0. My previous time doing this work and research and exploring more and more of the depths of Kanpot was a little bit before that. Even then, back then at that point in time and now, taking a look at the documentation that Kanpot will offer for you online as part of the repository when you do your research, unfortunately, it is a little bit lacking, right? I'm showcasing some screenshots and snippets of, oh, these are the protocols that are outlined and defined within the packaging that Kanpot provides for you or the templates you could use to quickly spin up an ICS device. There's nothing there. And that's kind of a big bummer. It's not too bad though, right? Because, hey, it's open source. We've got the repository. We've got the source code. We know Python. We've got our bearings in Linux. Maybe we can figure this out. And that's kind of exactly what we did, right? We started to explore Kanpot. What can we do with it? We mentioned templates. And you saw just maybe a brief second of it in that previous slide. You can provide Kanpot with a given template so it knows how to behave, how to operate, what to really do or what to emulate. We could quickly put together, just have this mental abstraction of maybe a power plant or a gas tank or a water pump or maybe a flat bare-bones, simple Siemens S7 PLC that we could work with, right? If I use that hyphen hyphen template or TAC-TAC template default, you might be able to see that argument shortened, kind of the shorthand case as TAC-T and then default. We could suggest and specify, let's just use the default Siemens S7 and get some access to these protocols, right? HTTP, Modbus, S7 COM, SNMP, et cetera. And it does include some other templates. This is just an excerpt. I did not include all of the ones that you may find with Kanpot currently in this kind of screenshot picture here. But the one that I find most interesting and most useful to us is that default template with the Siemens S7. Taking a look at that Siemens S7, again diving into the source code, operating with the utility, trying to spin it up and see what we can do. Once again, kind of run into some bumps, some speed bumps that are slowing us down. It's not doing everything that maybe we could have expected. As it turns out, Kanpot is a little bit limited into some of the functionality and features that it has. Or maybe it's just expecting us to go ahead and implement them or extend them ourselves, right? So if I'm looking at the source code for that S7 COM protocol for working with the Siemens S7 PLC, these parameter mappings, the bytes that I might send, maybe I'd want to read some data out of the PLC or write some data to it. Unfortunately, you can see here in this image, maybe we don't have the functionality in place yet. That request is not implemented. Bummer, right? Even in the comment just above here, you can see the inline Python comment there with that sort of hashtag or octothorpe. They link us to this web page, but that web page seems to go nowhere or not exist. So, dang. Okay. Whatever, stumbling blocks, maybe we can just roll with the punches, we'll go with the flow. At that point, we can do our own research, kind of learn a little bit more up on what all these protocols actually are. What can we do with them? So in our scenario, we wanted to put together a simple rudimentary tank. We wanted to get our own ICS device up and running, at least in our minds, in software within the computer, because we don't have a giant, however many tons, water tank, however many gallons tank, we don't have that physical hardware or that machinery or everything in the real world to actually do that. So, Compot was going to allow us with a little bit of legwork, with a little bit of our own thought and tinkering, be able to create a PLC. So, you can see I've kind of opened up a little bit of the source code here on the left, and I've needed to create some extra files. Some of that might just be, okay, let's, let's colluge together the functionality that might make these calls between trying to read data out of the PLC or write data into the PLC, etc. And just defining what this object is, thankfully, is just kind of an XML file. We can just configure it in a declarative sense. These are kind of the attributes, the keys and values that we want, maybe this object to particularly have, or the information we can read and write out of it. So, we faked a real world physical tank, right, maybe filled with water, maybe filled with gas, whatever we want. If anything, we just have this conceptual abstract mental representation of an ICS device and operational technology. With that, we had the PLC, right, we had the programmable logic controller with some of that code put together. Problem is, that's still just operating, it's still just acting as a thing, right. Maybe it's the brain, and we talk about some of the ICS lingo, the PLC versus the HMI. The PLC is literally the logic controller, it's literally the chip, it's the brain, it's the mind that's making all these decisions and doing things, but it doesn't have a way that we can kind of know what it's thinking. We need to be able to see that, it needs to have its own representation. So, then we bring in the HMI, or the human machine interface, right. If the PLC is kind of the brain, the thing that's thinking, making decisions, we need to be able to see that, actuated in reality, so we have to have a body for it. And that's what our HMI is, so we can actually work with, interact with that, move things with it, do things with it. That's the HMI that we want to put together. So, we actually ended up creating just a small, gooey interface. I actually did this in Glade in Python, kind of the, one of the, I think Glade is a, is a whizzy wig, or what you see is what you get. Editors for designing a simple graphic interface, but we would have kind of, these rows, or these kind of symbols that were indicating how high or how full the tank was. We would have kind of green lights, all in a vertical line there, and a column arose to say, hey, this is the current level of the tank, whether or not it's full, whether or not it's like running low, et cetera, et cetera. And we would include those values between temperature and pressure. And we could simulate this idea. We could emulate this operational technology. We would have some logic in there to be able to pull from that and update the actual gooey or the HMI in our case, but it needs to be able to stitch into the PLC, right? HMI needs to be able to know and hear, kind of understand what is happening on the PLC. So with that, we started to have to put some of these pieces together. Now, I know, disclaimer, right, I realize putting code up on a slide is stupid and dumb. It's not the best way to kind of get information across, right? I don't mean for you to have to be reading boring, stupid Python code off of a PowerPoint presentation for a talk. That might be silly. I do, however, want to show you how we kind of put this together, right? And again, forgive, please, my old Python two isms. I know the Python Easter's or the Python evangelists that might be listening are yelling at me. This is some time ago. And that is how we would be able to stitch together our HMI and PLC. We interact with just the simple socket for that seven protocol chilling out on port 102, connecting to it as necessary and sending some bites, sending some information in that protocol language to say like, hey, I want to know some information. What can you tell me? Kind of gather that information, send it all, all in that byte format and request some data. So you can see that data rec variable, data request, and then data three is what we receive and return from that, the information that we're gathering. With that, I could continue on in this function. And not all of that is included here in this kind of excerpt or the snippet of code here, but we'll start to kind of massage and pull out the actual information and data that we really wanted to know that we can reflect in the HMI and that GUI output interface. What's really happening here, though? What's really being done? How are we communicating? That's simply the socket, right? So all it takes in our case, thankfully with conpot and what we're working with, we just have a simple network socket that we can send and receive bites or data to. And we can do that with Python. We could do that with probably Netcat, honestly, if we even really wanted to. But having that in the code, I don't know, wrapped in code, wrapped in the mentality that we can do this in Python. We have these bindings. We can automate this. That's a big deal. We can simply automate interacting with the PLC. And with that, we could do a lot of stuff, right? Because now you've got the entire arsenal of Python and the programming mindset, methodology, anything that you want to do, you have superpowers. Now let's hammer this industrial control system device. And it's in the kind of caged and containerized playground and kind of encapsulated into jail because it's a honeypot, right? We're simulating this. We're not actually going to hammer and beat up a little gas tank or power plant or whatever we're thinking of. But we can emulate some threats and maybe tinker with them to see what we can do and how we can do them. That's kind of neat. Okay. While we're doing this, what's to stop us from checking out those packets that we're sending? Because we are going to be sending some communication, right? We are sending traffic back and forth when we're interacting with these protocols, Modbus S7, everything that the Siemens S7 PLC might be doing. So Compot will spin up all these servers and they'll work with them for us. But what we can do, acting as kind of our own adversary or whoever we want to be or whatever hat we want to be wearing, white hat, black hat, gray hat, whatever the case may be, we could listen to our own traffic. Take a look at that protocol, break it down, work with it, with T-Shark, some of the command line sniffing or listening utilities. Pyshark, again, if you want to automate that in Python, kind of wrap that all into our own sword, right? TCP dump again on the command line. Wireshark, super-duper easy. Now we're just operating in the GUI. Wireshark would make that incredibly easy. Just be able to see, examine, drill down in the packets and maybe we could see, hey, sending some requests from this Compot, from this industrial control system Honeypot, what data and bytes and packet headers are going to be necessary to actually communicate with this thing, with this device. That's an option and that's one way to go about it. We ended up doing that so we could put together some potential attacks, right? What could we do now that we've set up this gas tank, this water tank, whatever device that we actually want to beat up as our target or as an OT or ICS device? Some of the things that we came up with were simple network attacks, right? You've heard these before, you've seen these before, these are probably the most common things you can do. A man in the middle attack, why not? Set up a simple proxy, maybe we'll put a bad guy in the middle, right in between someone who is innocently enough actually trying to operate or receive information or do things with the endpoint target, the actual ICS device and we've got ourselves the bad guy just listening in in the middle and seeing all of those protocol statements come through. What do the packets actually look like when you say you want to lower the water level however many gallons or however much level in the tank? What does it actually look like when you are pouring in more water? Can we have that packet and maybe be able to determine what else we can do with it? Is there any sensitive information that might be included in that for some reason? I mean, there may very well be, right? If we're looking at temperature, we're looking at pressure, we're looking at actual real world things, maybe there could be some danger in that. But one of the really cool ones that I was just kind of alluding to was knowing those packets, what might be necessary to raise the water level or lower the water level or turn up the heat, increase the temperature. If we could replay that packet over and over and over again, what could we do? Could we pour all the water out of the water tank, make it just flood out, disappear, break, go away? Could we overflow the water tank? Could we absolutely ruin that entire container, that capsule, that actual real life thing? If it is something that we're controlling temperature or we're controlling heat, can I make this thing catch on fire? Can I burn down whatever power plant or whatever actual maybe technology hardware machinery that's kind of being at play, put at play in the real world, right? Kind of getting in the conversation of real machinery, real stuff. We would do this. We did this. We created this little replay attack where we would just simply take, you can see the bytes there, the actual data, right? Zeros and ones, the binary that we'll actually end up kind of representing as hex, we'll decode them so the raw bytes, they're packed, set up within the packet headers, and we could tell, we could repeatedly tell that PLC, we could repeatedly tell that water tank, keep emptying the water, keep lowering the water level until eventually it's all gone. We did this with a little scheduler. You can see this kind of function here, that full PLC. At the very, very end, we enter into another scheduled so we can repeatedly do this about every two-tenths of a second it looks like. Kind of neat. That's what we did. We can kind of see it reflecting our HMI. Oh boy. Conceptually, now we've lost all the water in the tank. What damage can we do in the real world? Another thing that I kind of consider about this, and we tie in all the concepts and the thought that like, well, now we've wrapped this all in automation, right? We've done this, we can create this in Python, we can automate whatever packets we want to send or do anything with those packets, and that's kind of cool because we could potentially fuzz different parts of the protocol. Maybe some packet headers there or some of the data or some information that we might send in one specific offset or segment within the frame, within the packet. We could do some damage. Maybe. We don't know. That's the whole point of fuzzing, right? We're just kind of throwing stuff to see what odd behavior, what weird unexpected data and input will make this thing fall over or break. How will this device respond when there's just a series of null bytes or random XFF bytes? Who knows? Who knows? Sometimes we don't. And that's kind of fun to tinker with and kind of play with. But that's the benefit. Going back a slide, just seeing, hey, I've just got a simple string and I can do whatever I want with it. I can send it to this PLC and how will this device respond? Kind of neat. Okay. So those were just some simple thoughts, right? That was just our small tests that we could do with this kind of honeypot. We could emulate the attacker. We could see what we could break. We could push the envelope with that. And a lot of times while we were looking through this, while we were kind of operating with this honeypot, this codpot, this industrial control system device, we would be noticing that all the traffic, all the responses, everything that the PLC was actually willing to tell us when we were giving, we were asking for information, that sort of thing is going to be sent out in plain text. I mean, not so much plain text, right? It's obviously going to be wrapped in its own protocol, but it's bare bones out there. It's on the wire. It's in the network. So maybe potentially anyone else in the network could gather that information. So you don't have to be on the specific machine having the conversation with that end target PLC, but just in the vicinity so that you could capture that traffic. So you could do that man in the middle attack. So you could do that repo attack, manipulate packets, whatever you'd like. So just a thought, right? If that's out there in the open, if that's just hanging out to dry, let's try, let's put a little bit of effort into separating, okay, the only things that need to talk to this PLC, the only thing that need to actually have conversations and communicate with this ICS device, those are the only things that should be able to, this computer has to have the need to know, right? Only the things that need to talk to it should be able to everything else. Let's kind of, I don't know, border gate that away, put that behind some doors, put that behind walls. So we could do this, maybe we could separate our network schematic with VLANs or some switches to kind of, hey, let's let's segregate and practice good defense in depth to lock down and kind of protect and mitigate some of these attacks that could be put on our ICS devices. Another thought with this, and I disclaimer, right, truth be told, I don't know how well this thought would work. Because if, again, all of our packets, the conversation, communication going back and forth between that ICS device is out in the open, well, we should encrypt it, right? That's kind of the knee-jerk reaction. Oh, how do you stop plain text credentials going through HTTP? Well, you encrypt it, you have HTTPS, you use SSL. I don't know if this would work all that well for these ICS protocols, right? Because it still kind of needs to have its own encryption there. I don't know if using SSL on top of that or maybe wrapping things with IPsec would work. So I'm admittedly operating at the edge of my understanding, and I'm eager to hear from you what you think if that is a potential option or solution. But maybe the tunnel mode within IPsec, if anything, the switches, the routers, the gateways could still make those proper routing requests and know where to send things, maybe at least at the tail ends of, okay, sending this packet versus receiving this packet to increase the water level or decrease the water level or turn up the heat, maybe those could be encrypted a smidge. I don't know yet, but hey, we're all in it to do a little bit more research, we're all in it to learn a little bit more. Okay, now let's start to wrap it up, right? We've had some conversations, I've kind of dragged you through a lot, and again, I still want to apologize. We, due to kind of the nature of how this unfolded, we wasn't able to put together as much of the real cool code and the demonstrations that we would have liked to see, maybe at a real live con, but hey, I hope you still enjoyed this sort of thing or at least got some ideas or you're interested in con pod and you want to go check it out and play with it yourself, I would really recommend it, you might be able to do a lot of cool stuff with this, recreate some of the same ideas or even do your own thing. So what are we looking at here? We're looking at Modbus, we're looking at S7, Siemens S7, S7 com, some of these ICS protocols, the operational technology, the lingo between HMI and PLCs, some of this stuff is a little old, right? Not always, but a lot of times, in the way that it's kind of being architected together, it could be insecure. Oftentimes, it's just inherently insecure because that information needs to go from whatever parties are asking for it sometimes, hence the PLC and HMI communication conversation. If that can be abused and taken advantage of, like even just again, the classic simplest network attacks we were just discussing, manual middle attack, replay attacks, just simply listening on the wire kind of manipulating those packets, fuzzing that data, that can abuse the device. Let's try and set this up. Can we lock this down with encryption? Can we at least kind of separate and segment our network so that things are compartmentalized, so the different parts of the machine read, the parts of the network that don't need to talk to the ICS device can't? That's just, I think, simple classic defense and depth, or least privilege, need to know. I think we can try to work through that with some of our ICS devices. Okay. Okay, I don't know a good way to kind of wrap this up, right? It's hard to kind of put this out there and say, sure, we've simulated some small things, some interesting techniques, some clever techniques and tricks we can do in an emulated environment, right? We're not working with a real power plant. We're not working with a real gas tank or water tank. Who knows? Maybe you could do some interesting and cool stuff with that. I hope you do. But if anything, I just wanted to show you there are some options. There are some things we can do. And you don't need to have a giant power plant or any of the other crazy mechanical ICS devices stuff. You can all do it with software and explore and poke around. Maybe try some of that adversarial mindset and see what you can do to mitigate it, defend it, protect it, or just learn a little bit more about this sort of thing. Okay, if you have any interest in chatting a little bit more with me, please, please, do not hesitate to reach out. You can find my email address there, johnhammond010 at gmail.com. The stupid YouTube channel, I'd love for you to go check out. We're almost at 100,000 subscribers, which is kind of unreal. If you want to see some of my code, for some reason, I promise it's not all old dirty Python too. There's my GitHub and you can find me on Twitter or join the Discord server and hang out with me and my community. So thank you so, so much. Thank you, thank you, thank you. Cannot say it enough. I really hope you enjoyed this conversation, this talk, this presentation. We can go even deeper in the weeds. We can kind of zoom in on this even more. If you want to, we can take it offline. Feel free to hit me up in an email or Discord. And if you'd like to, we can still keep taking a look at Compot. Maybe turn this thing up to some Python three code for our communication. Do some of that fuzzing, manipulating the packet headers, or trying other offensive techniques and actions being a good adversary. Thanks so much for listening, everyone. I hope you enjoy the rest of the conference. I hope you enjoy your time here. And thank you, thank you, thank you. Have a great day.