Deploying Honeypots for High-Fidelity Threat Detection and Intelligence

question. Hello everyone and uh welcome to my talk on uh how to prop uh deploy intrusion detection on where am I? My [clears throat] name is Anetacho and uh in my dayto-day I work as a security consultant at the University of Leeds um looking at security from both sides of defense uh offensive and defensive. I'm also heavily involved in um security architecture and uh dev secups. Today I'm going to talk a little bit about um cyber deception uh more specifically how we can uh use honeypot as part of uh that strategy. And the goal here would be to um complement our existing security controls uh in order to uh detect intruder in in our network

more quickly. According to the latest IBM cost of a data bridge report uh which studied over 600 organizations that suffered a bridge between uh March 2023 and February 2024, it took on average over 180 days to uh detect the bridge and uh over 60 days to contain it. Um so if we have detection technologies like uh firewalls, IDSS, EDRs and seams, why is it taking us so long to detect intruders uh on our network? Uh one of the reason is that um these technologies are um designed to look for evil uh whether that's signature based or behavior based. Uh they're searching for actions uh that appear malicious. And the problem with that is um attacker has become uh very

good at making their activity look normal making it [clears throat] extra difficult to differentiate them from uh legitimate users. So we need um a way to change the game. [clears throat] What if we um create resources on our network that have no production value? meaning legitimate users should never interact with them under normal circumstances. Uh for these resources, um normal would be defined as no interaction. Like if no one's touching it, everything is fine. But if someone does touch touch it, uh that interaction alone is um decisively abnormal and immediately actionable. And that um [clears throat] that principle is one of the fundamental components of uh cyber deception. So what is cyber deception? Cyber deception is a strategy

uh where we intentionally create and deploy um fake resources that mimic valuable part of our digital environment. And the idea here is to man manipulate what an attacker sees, thinks uh and does. And the key idea is this. If the fake resources that we replace we [clears throat] place on our network look and feel exactly uh like the real resources um an intruder will have no real way of differentiating between what's real and what's fake and all the attacker needs to do is interact with a single fake resource to be detected. So [clears throat] uh with that in mind, it means we can we can now use cyber deception to complement our existing security controls and to speed up the time uh

that it takes us to identify an intruder on our network. Cyber deception itself is a strategy and not a technology. Uh however, one of the primary technology used to implement it is is honeypots. So honeypotss are the actual technological resources that we place on our network that no one should ever touch. And if someone does touch one, we know something's wrong straight away. [clears throat] In um broadly speaking, uh honey pots can be categorized uh into three main types. Uh we have honey systems, honey services, and honey tokens. Honey systems are um entire operating systems used as a honeypot. Think of providing an attacker like with a full-blown uh Windows 10 device, a Red Hat Enterprise 9 and so on.

>> [clears throat] >> um using a full-blown operating system as a honeypot, it's some is something that's really difficult to do properly because that operating system might have vulnerabilities that you're not aware of and an attacker might do um unexpected things um and take advantage of a vulnerability that you're not aware of and break contain. So for that reason uh we're not going to be focusing on honey systems uh in this talk. Um, next on [clears throat] the list is honey services. Uh, instead of full operating systems, these uh mimic um [clears throat] specific applications uh services or network protocols, think of things like th web servers, f uh RDP server, VNC, MySQL and and things like that. And

finally, we have uh hon tokens. Um these aren't systems or services in the traditional uh sense. Instead, these are pieces of fake data or bogus artifact. Uh things like fake documents uh fake credentials, fake database tables, fake DNS records, uh and so on. And when it comes to deployment, these uh uh different types of funny parts are not mutually exclusive. Uh they're usually powerful when combined. Uh for example, you can have a system configured with multiple u [clears throat] honey services that also has uh honey tokens scattered around it uh file system. It's it's all about creating uh believable and enticing alerts for for the attacker. Okay. So we know what honeypotss are, we know their potential, but how do we

actually use them uh [clears throat] in real life? Broadly speaking, uh honeypot deployment fall into three uh main categories. Um research honeys, uh resource exhaustion or attack detection honeyotss. Um for the sake of briefly, we will we'll be skipping over uh resource exhaustion honeyotss today and focusing more at on [clears throat] research and attack detection honeyotss. So let's start with research honeyotss. These are the ones that you typically deploy um outside your network boundary um uh or maybe uh in the in the cloud uh to capture proliferation of worms um you know network scanning um you know what generic bad guys do or general thread intelligence uh collection um there's some value in deploying honeypots this way but depending on your

maturity level um this information may or may not be useful to you because um [clears throat] um it may not be useful to you from an intrusion detection perspective because you know when you expose an IP address um on the internet it usually takes less than 2 minutes before people start you know scanners and scripts kitties uh start probing it. So the fact that someone um is attacking it is not really a surprise but you can still leverage that for for other things but >> [clears throat] >> But here we are going to be focusing more on the intrusion detection um aspect. So next we have uh attack detection honeypot. Um these are going to be the

core focus of our discussion today and these are the ones that we deploy uh in our network that no one should ever touch and uh [clears throat] uh that no one should ever touch. And if um someone does touch one, you know, we we know something is wrong. And um to deploy these honeypotss properly, we need to fully understand ourselves. We need to understand where what our critical resources are, uh what we're trying to protect. But more importantly, we need to understand what um an attacker will do, what techniques they will use when they are in our network so we can properly lay traps that they will trip um when when moving around. Um so

basically we're trying to give them what they're looking for except it will be you know highly convincing decoys. Um so to fully to properly understand what actions [clears throat] an attacker will do when they are uh inside our network, we can leverage the MIT attack framework which is a knowledge base of uh various different techniques uh attackers will um very [clears throat] different steps attackers will take uh to compromise our network. It is broken down in tactics which is what an an attacker would try to achieve and techniques and sub techniques which is how an attacker would do it. So honeyots can be used to to some extent uh to detect uh most tactics in

the m attack framework but um today we're going to talk uh touch on a few example of how to detect things like initial access credential access uh discovery lateral movement collection and even data expiltration. [clears throat] All right. So now that we've um armed ourselves or gain us some understanding of of what techniques and attackers will um will will use on our network. How can we use honeybots to um detect that more quickly to gain initial access into our environment? attackers will typically either compromise one of our externally exposed resources like our web servers or VPN gateways and things like that. But based on um data breach report um in the past few years it's more likely that

they will gain access by um through a user workstation maybe one compromise through fishing and um once they have access to a system on in our environment uh especially in a Windows uh environment where everything is tied to a credential uh one of the things that they will um do is try to get more credentials. And one way one common way attackers will will try to get more credentials is by dumping them from the memory of a system that they already have access to. And uh with Honeypot we can detect that by uh planting fake credentials in the memory um of our systems and watch if anybody tries to use them. Another common way of um an attacker will gain

uh credentials will get credentials in our environment is by listening to um multiccast name resolution uh protocol broadcast like uh the ones used by linar uh [clears throat] net bios multiccast DNS and and things like that hoping to uh obtain credentials by poisoning the responses and uh we can detect this with honeyot uh we can set up a honeypot that will advertise fake credentials um using these protocols and watch if someone um tries to use them. It is very rare for an attacker to land into an environment and know exactly where everything is um where your crown jewels are, where your vulnerable systems are and things like that. So typically to get the layer of the land

they will have to enumerate uh they will have to search uh and find what systems are out there and and one way they do that is by scanning the network. They'll typically set up a subnet um on a scanner or a tool and it will go out and uh it will go out and find um all systems out there. Um and we can detect this with honeyotss by you know setting up service honeyotss around our network that they will um trigger that will trigger whenever their ports are are approved.

Looks like there you go. >> [clears throat] >> Um another another thing um to remember is that attackers are never you where they need to exactly where they need to be when they first compromise our environment. Typically [clears throat] um um they need to search they [clears throat] need to move around to uh achieve achieve whatever their goal happens to be. If it's um if it's malware they need to move around to deploy the the malware or ransomware. um if it if they're trying to steal your data, they need to move around to get to it. And uh one thing we can do with honeypot is set up um you know honey around our network that they will trip

when they are uh moving moving around our network and will be will be alerted.

Once an attacker has made it inside your network and moved around a bit, um they will start looking for the type of the data that they're actually interested in. Uh this could be uh things like your intellectual property, [clears throat] uh your financial data, your personal information, um anything of of value. And um >> [clears throat] >> um and uh with honeypot we can um detect these uh this kind of behavior by uh creating fake database tables or um fake documents uh inserted within real uh real data uh with interesting names or um something that will you know draw the attacker's attention and u be alerted when someone access it or tries to use them.

Quite often our network includes uh non-traditional IT systems uh things like um IP enabled boilers um industrial control systems uh building management systems uh [clears throat] you know all these types of of embedded embedded computing devices and uh these are gigantic avenues for attackers. Um they are huge target but the problem with them is they are typically uh black boxes from the traditional monitoring perspective. You cannot just install your EDR or C agent on the smart thermostat the start controlling your building HVAC system. And here uh honeyots offer a great opportunity uh to gain at least some level of visibility because we can uh deploy honeyots next to those resources um uh mimicking the application and

services that uh that they use. And um if someone starts um you know interacting with these uh embedded devices, chances are if a honeybot is next to them, they will also interact with our honeybot which at least from an intrusion detection perspective will give us an indication that someone is um is poking around. Right? So we designed a honeypot uh we deploy them. Um but that's only you know half the job done. uh we need to uh couple them with uh appropriate logging uh and alerting. I like to equate that to you know deploying a very high definition CCTV system but if you don't actually watch the footage or even worse you know if you don't connect it to a

recording device that's not going to be very useful to you. Um so we [clears throat] must um we should log uh the activity that happens to our honeybot and uh we should couple that with um we should make sure that all the logs are forwarded to a centralized location and we should configure proper alerting and incident response procedure so that um whenever someone interacts with our honeypot you know like uh we are alerted and we are able to investigate and u [clears throat] um invest investigate and respond accordingly. Now, the more believable our honeypot is, the more intelligence we might be able to u gather from the attacker. Let's take a service honeypot for example. Um if an attacker just tries to

connect to it, um we know they're there. Even at this point, even if they realize it's a honeypot and stop inter interacting with it, at least we know they're there. But if you make if we make it believable enough and uh give them an option to authenticate, um they might authenticate using credentials that they've already they already have access to in our environment. And this might give us an indication of um whose credentials they have. Um once they've a authenticated if we give them access to a file system they might start running keyword searches looking for a specific type of data or they might you know be looking for specific directories and this might uh give us an indication of what they're

looking for and um often time they will start you know uploading or downloading their tool set which uh will give us an indication of what they might try they might try Next, um here's a real life sample where we collect things like connection, authentication, commands, and downloads um with with Honeybot. The uh top one is from a honeypot called um ADB Honey, which is a honeypot that emulates uh an Android device. And um [clears throat] we can see where the attacker is coming from in our network and uh some of the actions, you know, taken uh on on the system. We can see they've connected. Authenticate. Um, you know, type some command, download some scripts from the

internet and then continue typing some more commands. Below we have authentication logs from Honeypot called Diona, which here emulating a Microsoft SQL server. And we can see the attacker trying to authenticate uh with credentials, domain credentials that they already have access to. Now this next topic is super super important because you do not want your honeypot to help the attacker's agenda. Uh therefore we must adequately harden our honeypot so that an attacker does not do anything beyond what we allow them to do. Uh and here are a few resources that uh you can look into when it comes to to hardening. The center for internet security CIS uh publishes benchmarks that will allow you that will help you uh harden your

operating systems and application. They're always a fantastic starting point when um when working on your hardening configuration. [clears throat] Uh honey services are typically script and it's generally uh recommended to deploy them um in container within the system where you want to deploy them rather than on the system itself because containers give you uh additional isolation option uh that you may not have when deploying it directly onto the system. Um, CIS benchmarks are typically uh distributed in PDF format which can be a bit time consuming when it comes to copy and pasting and building your configuration path. Um, but uh luckily there are other publicly available resources that you can leverage when it comes to uh hardening your systems on um

on a Linux for a Linux host. You can for example um leverage the compliance as code project which uh provide you with um bash scripts anible playbooks that you can use to harden your system compliance to uh the CIS benchmarks. And for Windows host you can leverage readyto use group policy objects provided uh by the Microsoft security compliance toolkit or all the disastics. There are um a lot of products out there that will make it very easy for you to deploy um honeypotss. Some are commercial uh but some are free or open source. Now um here are a few um open source option uh [clears throat] that you can look into. Um they all provide

you with a framework that makes it easy for you to to deploy um things like service honeypot. Um we talked a little about a little bit about you know the importance of centralized logging and monitoring. Uh on this list open canary and tapot give you an option to deploy um [clears throat] uh an infrastructure that will uh automatically monitor your honeypot. So if you don't already have one, you know, those are very good options to check. If you um want more tools, um I would recommend you checking the awesome honeypot uh project uh which is a community maintained list of dozens and dozens of of open source honeypotss. So um yeah, I recommend checking it out.

Now, when it comes to deploying um service honey pots, for example, here are a few things that you may need to think about when when doing them, remember we are telling a story to an attacker and um and we want that story to be as believable as possible. So, when it comes to uh service honey deployment, these are a few thing that you can think about things like your port configuration. We um talked uh in the previous slide a little bit about some framework that will allow you to deploy multiple service honeys uh on on a system and in some cases they will allow you to have one that you know listens to you know all 65,000 ports uh

uh on the system. Now, if you're doing something like resource exhaustion and things like that, yeah, that might be useful. But if you're purely deploying a honeypot for intrusion detection, um, and you're trying to make it look like a production resource in production, it's never the case where you have systems, um, I mean, not never, but it's rarely the case where you have systems that listens to uh, all 65,000 ports. So when it comes to port configuration um usually uh less less ports are often more believable. When configuring your honeypot, you'll have to decide whether to make it similar to production or different from production and there are pros and cons to doing it one way or

another. Okay. When um when making it similar to production, it's less likely to raise suspicion. But uh there are [clears throat] but there are little tweaks that you can make to draw the attackers's attention to it. Things like making it slightly more more vulnerable. Let's say you're deploying it next to a web server that has a web port um RDP and maybe SMB. For your honey port, you can make it web port, RDP, SMB, and maybe add something like VNC. uh if your production resource is only support SMBV3, maybe make your honeypot support SMBV1 or up to you know something that will uh draw their attention. Uh you can also give it interesting names um that

suggest you know the resource is less secure. Let's say you have a naming convention that identifies your production resource as prod um you can um deploy your honeypot and and call it dev or test or stage you know something I would suggest it's less secure than the production resource obviously don't call it honeybot um if you [laughter] if you um if you use a um if you want to make it very different from production um that's more likely to raise suspicion but some attackers usually look for one of targets or um outliers. So depending on who you're dealing with, you know, they may or may not take the bait. Um when it comes to honey tokens, again,

I will invite you to check the honey um the awesome honeypot uh list uh that has, you know, a bigger list of um honey tokens out there. But I thought I'd mention a few here. You can use invoke runners to place credentials memory. you can use uh [clears throat] responder guard and uh and then you have um one of the NVBS which is uh canary tokens which allow you to deploy you know like um all sorts of of of honey tokens around in your environment. Now honey accounts are one of the uh easiest uh honey tokens to deploy in your environment. And here are a few things to think about when it when deploying honey tokens. um obviously

make sure it doesn't work in your the credentials don't work in your production environment and you can monitor things like a fail log on or account lockout you can allow it maybe to work in your honeypot environment but please don't make it work in production uh in an AD environment um when you when setting up a honey token uh a honey uh account please make sure the login count is not zero because zero means that account has never been used. Depending on on what you're getting trying to get the attacker to think that account is used for advanced experience attacker will check uh this value to see if that account has has been used before or things like that. So

you can use something like a a script to log into your environment multiple times and uh increase that number. Um, and when deploying these, you also have to put them in locations where you are sure if someone's poking around where they're not supposed to, they'll find it. You know, things like um, put it in a config file, uh, somewhere within your net lo share, someone poking around your active directory environment, they, you know, they will be looking for places like that. um shares that are available to all users. Things like group policy preferences, you know, like you can name in like test change local admin account on all systems or something like that. Even if it's not currently deployed to

an OU to or to some machines, the fact that you say test, you know, suggest that it was used at some point. So, you know, they they might try it. Um or you can make it look like um it's a shared account and we're using the um the user description to store the password. Um yeah, that we've seen that in environments. So, uh yeah. So, so things like that. So, we we talked a little bit about um cyber deception uh but we've we didn't even scratch the surface. uh a few years ago m MI maid came up with a m engage framework which uh goes into greater details um uh on what you can achieve

using cyber deception. So if today's talk picked your interest in cyber deception I will encourage you to uh check out my engage. So key takeaways. Um I think I'm I only have like 30 seconds. You know um you can leverage cyber deception to speed up the um uh detection of intruders in your network. Um you know combine it with uh centralized logging. Please don't um allow your honeyots to advance the the attackers's agenda. and uh check out mighty engage questions. [applause]

So, uh we we unfortunately we don't have time for questions, but I'll be available in the corridor. Anybody has any questions, please in the corridor. All right. Thank you so much. [applause and cheering]