Conor Aitken - Leveraging Honeypots

Thank you very much because otherwise we'll run massively over. So I will hand over to Connor talking about deceptive defenses leveraging honey bots in OT environments. Over to you mate. >> Cheers. Um

hi everyone. I'm Connor. Uh I currently work as a threat detection engineer. Um I'm crowd strike but uh what this presentation uh comes across is it it's all my experience uh in my prior jobs. Um sorry just give me one second here. Um so nothing discussed today relates to sort of my current uh work. Um, my prior jobs I spent about seven years working in mining, water, energy, transportation. So that's that's both sort of rail uh port facilities, that type of stuff. Um, I my certifications there, you know, I've uh done the GISP, the the grid, so couple of sands. If you guys are interested in looking at OT security, I highly recommend them. Um, I'm also a

member of Professionals Australia. I know there's a couple of other members here as well. Um it's a union for IT workers. We do have a union with all the layoffs and reduction in forces um at various tech companies. If you're concerned about that or anything else, um come chat to me later. So why deceptive defenses? Uh this really comes out from participating in a number of risk assessments and things like that where I'm sitting at the table across from some engineer, some cyber security um expert from a client system or something like that and you can propose honeypotss as a potential control um to help somewhat offset some risk of something and and quite often uh you

know these controls will get rejected and things like that and I'm I'm just sitting there looking at the person crossing the table from here and just like you just think this is too hard and you don't know what to do. So what I hope to get across here is is um in a lot of these legacy systems your seam your nits um your endpoint defenses might not be appropriate because of the legacy environments you're putting them into or they're deemed too sort of high risk to to touch anything on the the endpoint systems. Um, so what I hope is that by the end of what we're doing here, um, you guys will be able to go to

work tomorrow and hopefully able to play with this um, and set potentially set something up in about an hour, right? It's these are not it's not a scary prospects. It's only how you architect it and how you you position it and how you set it up um, which is really what you have to worry about. So what we're going across here just to touch a brief history on uh honeypotss I'll go through the purpose types uh use cases I will give you some practical examples of where I have used this in the field um I'll talk about the global use for people who work for large companies who have a um a large distributed um systems uh potentially

I'll show you how we we'll see if my uh VPN plays nice um with actually we're being going to show you a live instance. So Honeyart's old intelligence gathering tool um you know sir Francis Walsingham which was like Elizabeth the first spy master um you set up fake channels to to deliver or collect information for some people involved in plots against her. Um, you can find talk of people utilizing things similar to honeypotss in a lot of um, intelligence uses or espionage uses uh, throughout history. Um, you know, one of the more common scenarios if we're thinking about cyber security is the Kaku's Egg by Cliff Stall, which is what I would say is recommended reading

for anyone in cyber security just because it it it's a really great story to start with, but it it also provides a really um awesome technical insight in to a lot of the foundational concepts which we still base our career on. So St was a physicist on loan to his uh university's IT department. Um and they had an accounting error on um because they had to pay for CPU time back then between different departments. Uh and so after a long investigation, you identified a hacker coming in from Germany um and utilizing their servers to try and break into uh US defense institutions and stuff like that. Um it was a long process to track the

hacker. So the the hacker was coming in from the university of breman um and would go through uh the German datex which was the the German post office essentially. It managed all the internet in Germany at the time um went through Timnet International which was uh sort of a switching service between international carriers. The the problem was you had to keep the the hacker on the line. So on the phone line, literally long enough for someone in the German post office to trace the cables to work out where he's coming from. So to do that, they created a honeypot uh with fake defense uh grants and documents and things like that to hopefully be able to keep this hacker on

the line to work out exactly where he is. So, like Sir Francis's traps for Catholic spies in Elizabethan era, um, Skulls Honeypot gave false info to the attacker. This deception prevented the attacker from strolling elsewhere through the network. Uh, because of this, the honeypot um, the attacker sorry correction sorry because of the honeypot, the attacker was able to be tracked and then ultimately stopped. So while it's unlikely in modern era now we would be able to you know physically track and arrest the hackers that we see in our systems we can still deceive them and then by deceiving them we're preventing them from potentially attacking assets that we do care about um and you know

deceive them and hold them up long enough for internally for us to be able to track what they're doing where they're coming from. And ultimately this all comes into a consideration which is called active defense. So moving on having a look at our uh the purposes here. So this is probably a common uh conception of what people think about honeypot. I mean you've got the uh the Norse attack map which um was great when I started in cyber security because every executive walks in you could just throw this up and it's like look we're doing something. Um, but this is the the typical of what you see for for honeybots external systems providing lots and lots of information. Um, but

not really that much utility and that comes down to hey you're collecting raw data and raw data isn't necessarily intelligence until you actually analyze it. you know, an IP address isn't intelligence until you start doing something, until you start applying context to it. So, this presentation won't really be going into um looking at intelligence or developing intelligence. There are a lot of utilities online that you can um explore if this is something you're interested in. Um yeah, honeypot traffic. So, the deception of the honeypots, which is what we are focusing on here, is convincing attackers your honeypot is a legit valid target. Um, if you're thinking about the Swiss cheese model that everyone's familiar with, a whole

bunch of holes and eventually someone's going to find a a hole that lines up all the way through. Um, you know, that they might already be in the network somewhere else, um, and looking trying to find another hole. We want to be able to provide them with that hole and focus their attention and focus their time on that so that they're wasted and we start getting alerts into saying, "Hey, someone's trying to check something out internally." Um, we're collecting this information. We're acting on it as part of our active defense. So, this is the DKW hierarchy. Um, are we familiar with uh the first instinct fallacy? So that the the first time you come to a conclusion about something

you're seeing, it's really hard to be able to shift yourself mentally off your original conclusion. A lot of the data, a lot of the patterns and things like that you start seeing unless you go into some sort of structured analytical technique where you're breaking out the um the data that you're seeing and and thinking about it in different ways and thinking about it with different conclusions in mind. you'll tend to start patterning everything into your first instinct. What we want to do uh with our honeypotss as a deception tool is start interfering with this DKW hierarchy. So the DRKW hierarchy we want to be able to promote bad data from which the wrong context will be derived which means they

have now bad information about what's happening inside our network. they can apply the wrong knowledge that they have to that information um and then their insight is correct uh sorry uh apply the insight to it i.e. their own TTPs and generate sort of bad wisdom from what they're doing. And and through this method of us being able to create and craft tools internally in their in our network which they're going to waste their time on um we now get an insight into what they're doing.

So uh Honeypots's active defense, this is a term that I keep coming back to. So we want to have um these tools to be able to provide us with potential early threat detection. So the traditional form of honeypots that I was talking about where you get your cool Norse map and that type of stuff that's sitting at the information stage all the way on the far left of uh the active defense uh life cycle. Um we want to be able to put this into active defense where it's like we're actually doing something about it. we can um the we're gathering information on on the TTPs and we're strengthening security controls actively. Now I'll touch on types uh to just to

make sure that we're on the same page about what honeypotss are and and and what they do. Um so firstly low interaction. These are quick. These are lightweight. A lot of these tools you can find on GitHub. um they simulate limited services. So you have something like just an SSH endpoint or a open FTP server, something like that. Uh where they detect they log interactions with minimal sort of resources applied to them. They're really nice to be able to be able to chuck on a Raspberry Pi and throw somewhere and connect it up and that's all you have to do. Um a couple of examples, Dion, Carrie, you can find these tools online. high interaction ones. These ones are

tools that do require analysis applied to them. So if you find yourself short on manpower resources, potentially leveraging low interaction honeypots is what you're trying to do in in your teams where if you do have the resources and potentially do have an intelligence function that you can rely on within your um cyber security team structure, then this might be a better solution. You have things like um liar bird which will have a vulnerable web application intentionally vulnerable web application but you're man in the middle of all the traffic just to see what people are going on from these you can generate more in-depth uh understanding of stack as ttps uh of course um you do have canaries

that they're really simple really easy to do you can do these yourselves if you're going to shove it into active directory um or you can do your own DNS logging that type of Um, things does their canary tokens, but it's easy enough to set it up yourself. So, I'll just call out here as a potential tool you could utilize. Oops. Yep. Things. Um, so our deployment considerations and risks. So, each different type has its own risks associated with it. So, if you are deploying it to OT network, you're going to have to consider this when you're planning out your architecture and planning out your controls. high interaction honeypotss can essentially be considered full systems. If we think back to the example

I had at the very start with Clifford Stall and what he was doing to try and track down that German hacker um that had a full system of data of grand information and uh emails and stuff like that um which he put in place to be able to um deceive his hacker. Um, so it it takes a lot of work and takes a lot of um time to set that up. You want to be able to make sure that these systems that are potentially full interactable systems are properly isolated, you know, from parts of the network where it could be someone is able to break through or break out of the honeypot that you've had into some other

part of your network. um and you don't want that to to affect your critical control systems that you're concerned about. Um with alerting this can be very difficult if you don't manage your alerting strategy very well. Uh at the very end I'll be I'll be showing a tool um which I've utilized which really simplifies collecting logs from a whole bunch of different honeypotss into one centralized location. So I mean you want to figure out how you can you know if you aren't utilizing a seam product because you don't have one dep deployed to your OT environment do you have some other aggregation method that you're utilizing some other way to get alerts get information out of these honeypots. Um

this really should be considered as a whole of operations approach. This isn't so much a detection engineering talk, but uh Palunteer's alerting detection strategies is probably a good place to start if you want to um start conceiving how you're going to like map out these alerts. Uh and and finally, uh maintenance. You honeypots for especially for external systems will require upgrades to defeat mass scanners. uh if you are hunting for information, if you are hunting for intelligence, um internal maybe not so much. Uh but this is still a risk to consider. You know, these are live systems. You do have to maintain them the same as anything else. Uh here is an example from Carrie, which is a honeypot. Um

this is a GitHub issue from 2021. Essentially, a botnet figured out, hey, we're getting trapped in Cry. Let's figure out, let's set up a bunch of controls to see um bunch of commands to see, you know, is this a honeypot system that I'm connecting to and then not complete the last stage of its attack, which is what this honeypot was designed for to to collect the malware that's dropped. Um very briefly, a table to sort of understand the purposes, the uh the goals that you're trying to achieve. So utilize the tool that's appropriate for the job that you're trying to do. All right. Uh touch on use cases. There's are quite a few different places

where you can deploy um honeypot systems. Firstly, the very obvious one um the detecting sort of scanning port uh reconnaissance that type of stuff. Um, you can sit this between your IT and your OT environments if you do have that sort of level 3.5 DMZ. Uh, where you do have access through for one from the other. I don't know why those boxes are white. That's annoying. Um, blue you have your IAS environment. Red uh you have your your IT environment and your honeypot in the center. Um, so sorry about that. I don't know um why that converted to white. My bad. Um monitoring untrusted vendors. So you're having um someone like Seammens, someone like uh Schneider or whatever

coming in u remotely accessing your your OT network. Um and so you have all your potentially untrusted bad actors over here and they're accessing a jump host in the center. um you know those accounts could be compromised by someone. Um and you want to set up your honeypot system to be able to say, you know, if someone accesses my jump host and they don't know what where they're going at the end of the day, um how can I make sure that I collect someone who is engaging in reconnaissance activity? So, this is a good place to be able to put a honeypot um that sits offside of your um IS network uh and collecting um

potential traffic or potential reconnaissance after someone's already compromised a third party account. Uh dev test zones. um if you're going to be able to replicating your uh your OT environment into a development zone. This is often doesn't have quite as stringent controls, might not have as um a as strict security or not might not be collecting all the logs from it. But it could be something where some third party integrator comes in and has access to how to set up this in your uh dev environment in your UAT environment before you push it out into uh the production systems. Uh again this is where you would want to set a honeypot to say you know is someone looking for

systems which shouldn't be there is just doing generalized reconnaissance and you want to try and catch them at that point. Um finally you know legacy systems uh I'm sure this being WA there's some people here working in in mining oil and gas you know you have a a conveyor weighing system which is maintained by some guy who works out of a shed in Dongra or or something like that. Um there's all sorts of weird legacy tech which which lives in these environments. I mean as sort of one example here I went into a a risk assessment activity and you're looking at um it was for a freezing works and it was a system that maintains you know the the conveyor

speed depending on the weight of the the cattle or the the the lamb coming in on the through the slaughter house. Um, and you I was looking at it on a Windows 2003 server. Cool. Um, but all the all the uh sensors and stuff were communicating through something I didn't understand. I said, "Oh, you know, um, what is what is this communicating on?" Oh, this is Dave's protocol. Oh, who's who's Dave? He worked here about 15 years ago. um he he's he's retired now and you know helps us when when we need help. It's like okay cool. Um I have a bunch of questions you know where where can I ask him? He's like oh we'll put it on the

list. Um and you know he he sometimes the the nurse helps him remote in on team viewer uh because we get him to help him out when he has a good day cuz he has dementia. So there's all sorts of weird stuff that exists like that which you don't realize is controlling some of these systems. So a couple of practical examples um railway lateral movement. So I just need to be clear here. We have one railway provide passenger railway provider here in WA. I'm not talking about them. This is somewhere else. Love you PTA. Thank you. My boxes are wide again. sake. Um, so this is a new train station for passenger rail um expansion. Um, the

systems were commissioned sort of with minimal cyber security requirements. At the start, the station BMCS, which is a building management control system, which handles all the the lighting and the air con and the vertical transportation systems, elevator, escalator, that type of stuff. um was connected in had a HMI server uh system which is this box here. Um great. The vulnerability that we found is that post commissioning for this station um there was a main switchboards so that the power control uh switchboards uh actually had a little web server hanging off them uh which is where they um would facilitate uh shipping um CSV files and things like that which would be accepted by the BMCS

uh HMI which is how they built all their pretty graphs and stuff like that which people would utilize. this uh main control uh board which is this server thing here. Sorry for my labels again actually had access into linewide PCS which is power control system which controlled all the power for all the trains on the on the train network. Theoretically you could access the web server put a web shell on there and then access the uh linewide power control system. We couldn't put a um we we considered, you know, can we put a NIDS system here in the power control network while we get this defect fixed in the main control boards, but the switches there

that all legacy that didn't have span ports or anything like that that we could pull data out of. So what we ended up doing is putting a honeypot off the side of the um that was accessible by the main control boards um to see hey if this was ever exploited if someone did figure this all out because you know these HMI systems were only protected by one of those wooden doors that you see at the train station which is locked and it says communications on it. Um and it was just a s computer that was in there that was always logged on. um you that would the reconnaissance would hopefully hit the honeypot and would

identify that someone is potentially looking at the power control uh system network. Um this was all so they could get the defect fixed in the man control boards first. So our interim monitoring solution was put in place while the defect remediation happened. So it managed to um mitigate the controls for our systems um for long enough. I mean the defect control the defect defect process still took 12 months anyway. Um but that's pretty good time and yeah then there was an upgrade planned for the power control system network to say you know it's probably about time that we replace these switches after 15 years. Second case study looking at a water pumping station. Again we have one water

utility in WA and it's not them. Love you water. It's somewhere else. Um yeah, white boxes. Um we have a remote pumping station. So this was somewhere in Australia. It is a remote pumping station uh for water. Um physical security is very minimal there. You got a barbed fence and because it is remote, there wasn't good internet service. So you didn't even have CCTV at the time. um can't have a seam pulling logs from those systems because the internet link that they had just wouldn't couldn't have all that data coming through. Um and also American companies really don't understand low bandwidth. Um that's something I've I've continually uh come to learn whenever I've deployed a new product.

Um, so we couldn't put the link there between the IAS network and the the firewall at the remote pumping station. So what we what we did is we slapped a a small honeypot just on a Raspberry Pi honestly off the in the same rack at the remote pumping station. And this would be the only thing that would send logs rather than collecting logs from everything else. So really the the risk that we're trying to mitigate is someone comes up to the remote pumping station, goes in through the lock store which has a key lock and that's about it. um accesses the the systems in there and starts looking around to play with things. So um that is is that let's have a look at

hang on. Seems like someone's trying to log into our remote pumping station. So we we got a suspicious alert detected for that one um about nine months actually after we put the solution in um comes through to the sock and then you end up calling the the cyber security engineers dealing with the OT side and they're like we don't know um what's your what's your plans here? We don't. Yeah, we never made that IR plan that you told us to. No CCTV. As I said, they call the the uh the maintenance planners. Maintenance planners have nothing on at that site. Cool. Uh call the local security contractor who uh when he isn't doing this is is working at target country.

Um so he heads out there and rolls up in his Hilux uh just as um so he heads out and finds our local worker uh out there. So despite the coordination between our security team and the maintenance planners, it was actually this guy was out here. He was working for the uh the mothballing team removing old equipment from the site and I don't have a communication between them of course. Um, and so he was trying to make a change uh to some of their old equipment getting ready to to pull it out and just basically hit the wrong asset. Um, so what this came out for us, you know, it was it was a pretty good

solution. It was pretty validating to say, hey, look, you know, this this kind of this kind of worked for what we were trying to do. Someone that we didn't know was going to be out there accessing our systems. Um, and you know, even though this was a false positive, it was still a win for us. Uh it meant that hey you know that I plan that we said you guys should do you should probably do that one. Um and we also found that the asset inventory system that they were working off um was there was some errors in there. So global use if you're working for a site with um systems all over um yeah

white boxes um you know if you're going to deploy your honeypot environment to the edge you can gain unique information about potentially who was attacking you. Just going back to getting information, getting intelligence about your honeypot deployments. And this is great if you have uh multiple sites all over because you can start getting idea of what's unique to different sites. Um this also works uh internally, although hopefully you're not getting a lot of reconnaissance internally anyway. Um when you're deploying to the edge, you're going to get a lot of the noise of the internet and that's just all the scanners and stuff that happen all the time. There are ways to remove that. I mean, you can manually go through and

you can look and you can say who's hitting me all the time. There are other people who develop these um scanning lists themselves of, hey, here's the common bad actors. There's one example if you trust QR codes. Otherwise, there's a link. Um, and excluding mass scanners from your list of data that you're having a look at can really start to reveal like, hey, what's what's different here? What's new for me? And that enables you to start getting a global context of saying, you know, what are we seeing at every single site? What are we seeing at only our sites in Australia or only our sites in WA and what am I seeing only at this specific

site itself? And through those stats, you can actually, you know, you can do cool things of saying like, hey, you know, executive, we are we're getting all these attacks specifically at us and here's how I can show you that. So you can do do this yourself and this is the how um where to start you know you can decide sort of what honeypot for what solution you want to try and achieve there are tons out there on GitHub which you can go through you can explore you can try and work out which ones you want um or this is my favorite which I've started deploying at different sites you can use this tool by Deutsch Telecom

called Teapot. This is an all-in-one honeypot platform. Um it's the honeypotss are all composed with Docker, so you can choose to what to pull down, what to deploy, where it automatically gets um dumped onto an elk stack, which means that um you don't really have to worry too much about the the connection between trying to drag stuff into your seam and stuff like that. Literally three commands and you deploy this and it's set up and running and it's operational. Um the elk service as I said runs on honeypot. Uh it has engines to provide you a secure way to to manage and operate it. You can deploy this internally, you can deploy this externally. It doesn't really matter.

So where to start for all of these is all of it. It's it's just that simple. You get your pretty Norse maps so your executives know that it's worth spending money on you as well as graphs to keep managers happy. And because it's a distributed deployment system, you can have it and you can have say, "Hey, for this one site that I'm deploying it to, I can put one honey on my BMCS, one on my power network, um, or one on some dev infrastructure that I've got." Or if you're multinational, you can say, well, I'm going to deploy one to a power plant I have in Spain and one I have to a power plant I have in Australia and see

what's different between the two. Um, that's sort of what I was doing with the last job and I was uh when I first wrote this, I had a practical demo to show that, but um maybe now not so much. Um, live demo question mark. Um,

just give me one second.

It's not sharing that screen.

Sorry, my live demo question mark is very much a question mark. Um, if you want to check that out, I can show you the deployment that I have set up, but for whatever reason, it's not showing up to the top screen. Um, key takeaways for this. Um, honeypotss provide um you with critical visibility that you might not have elsewhere or you might not be able to deploy elsewhere. If you have um systems where you have low bandwidth or you can't really touch too much within that network segment within that zone, then this provides you with an easy monitoring tool where you don't have to go through the arguments of saying, "Hey, put my agent on your

system, please, or hey, we need to set up some sort of other SIS log collection method." This can all just work again with literally three commands. Um, deciding on what honeypotss you want to set up in different environments means you can almost customize it to be your site. You can go through all those tools that I I showed on GitHub. You can customize the code for yourself and you can you can put it with your own branding. So, it makes it look like what's expected for your environment. Honeypots sort of within the active defense role. they detects unusual activity before it reaches critical systems when people are doing those reconnaissance within those those zones where people come out um where you might

not have other uh controls that you're able to do. You can get valuable data on attacker behavior and use that to you know update your detection logic sort of live as you're seeing it or or put in security controls ahead of the uh attacker as you're trying to get them out of the system. uh or it gives you time to be able to track down sort of where they're coming from and and understand their TTPs. Um finally, sort of some couple of key considerations. Uh choose the honeypot type that's relevant for not just the systems where you're deploying it, but also your team. There's no point putting a couple of high interaction honeypotss in different

areas if you've got a twoerson cyber security team because you're not going to be able to manage it and it's what's the point of putting that one in. Um placement is critical to be able to ensure that the honeypotss are in the positions where attackers are likely to come through. This is where you're, you know, deploying the honeypot should be off the back of a risk assessment exercise where you're understanding where you have risk that you need to put controls in. Do I have a risk for a lateral movement from a vendor supporter? Do I understand, you know, truly where um am I confident about this guy in Dongura uh actually having good cyber security on his end and managing

his identity? Um and you know, regularly review the honeybot data. It's no point just letting this log because it's not going to be part of your active defense cycle then. It's just a logging tool. Um thank you. Uh you can find um all my presentations there and you can find uh the teapot tool uh which I recommend you check out and deploy yourself at the other QR code. Um any questions [Applause]

[Applause] great. Um just you spoke a lot about um attack looking the attack coming in through the box. Um, have you had any experience in actually emulating the end uh device, so the the sensor or the PLC or whatever the case is right at the end uh emulating it um and using anybody's hitting that which is not an active device. Um yeah, the the question there was um have I had luck um I spoke a lot about people coming in um and that lateral movement risk. Have I had luck with um emulating end device the the PLC systems that type of stuff? There are honeypotss out there which which do that. It requires the the customization of of um

trying you know truly understanding your your equipment and being able to um present it in such a way. the there are um tools out there which replicate the um Stevens S7 endpoints and things like that uh which you can use and it collects all the commands that would get sent to it and stuff like that. Um the question would be sort of to think about you know for your your risk control and where you putting those controls in. um you know at at that point is that the most appropriate place to put those type of honeypotss or are there further controls upstream where it would be potentially more appropriate or you're going to find more information those

type of putting something at that level um down at level zero or level one um where you would see those type of PLC's and things like that that's where you know more you're seeing hey something's communicating to something which I wouldn't expect and that instantly triggers, hey, this is something really bad to to go check out. You wouldn't really be collecting too much information at that point. >> How many deploy how many deployments of like cutting plots are you kind of seeing actually modeling industrial control systems? >> Um that are that are publicly out there. Um there's one mining system called compot which which people tend to use. Uh it's the it's the one that that looks at um

the seaman systems. But a a point to to to understand about industrial control systems is at that level 3.5 which is what we call the industrial control DMZ level three sort of operation control things. You know they look very similar to IT networks. you don't need a lot of specialized tools to be able to replicate or or to be able to present an image of of what an industrial control network might look like um at those higher levels. I mean, you really don't want anyone progressing lower. You don't really need to dedicate too much time and effort into emulating other behavior. you can make a very convincing um you know top level overview which hope

hopefully should catch or deceive um most people that you're worried about.

>> Cool. Uh yep. Sorry.

U most unusual case study I've had so far. I mean the two I put in there was some of the um were perhaps the the more unusual one. The the passenger rail network was certainly interesting to be able to find first that u you know why is there a web server in a in an electrical switch word to start with? Um and then understanding the full scope of being able to say you know okay this can actually communicate to other parts of the network. Um, that one I put at the top.

>> Yeah. >> You mentioned to about that running something that linked to or is that >> um that was a question about pay? No, that's that's running. I mean that's been we've been running for what 30 years. Professionals Australia. >> Oh, >> cool. All right. Thank you.