Honeypot detection through machine wear and tear - Matilda Moore

Hello everyone. Thank you for coming. I'm Matilda and today I'm going to be chatting about the research that I did for my dissertation for my undergraduate degree. I investigated how we can detect honeypotss particularly through machine wear and tear. We'll get into what that means in a bit, but first a little bit about me. So I'm fairly new in my career and I've spent the last four years being a side degree apprentice at UI and at Leonardo UK who are just across the road at Bristol Business Park. Recently [clears throat] I've just started a role as digital forensics and instant response analyst within the Leonardo sock team. I've had an interest in deceptive technology for the last

couple of years. started off as a hobby, something I was playing around with, experimenting with, and then turned into something which I did my research on for my degree and is now something that I'd like to take further into my career. This is the first time I'm speaking at a conference, so thank you very much for having me. >> So, let's all get on the same page. What is a honeypot? There are varying definitions, but for me, a honeypot is a decoy system where we can observe adversaries tactics, techniques, and procedures in a controlled environment. They should in theory only attract malicious actors. Therefore, it creates really highfidelity threat intelligence that we can cycle back into our blue

team practices. Honey pots can be it, they can be OT, they can be real systems, they can be emulated via scripts, but they're often classified into three different levels of interaction. So the lowest end you have the low interaction honeys. These are typically emulating a service, for example, an SSH port. The next level up, you have the medium interaction honeypot. This is taking that low interaction emulated port and it will add an interface for example a file system typically also emulated by scripts. And finally you have the high interaction honeypot. These are more likened to a highly highly monitored forensic machine where it's often real infrastructure and every single action is monitored and logged. Honeypotss are great apart from they

have one big problem. What if your attacker knows that they're in the honeypot? A trap is only a trap when no one expects it. And the same is true for honeys. If your adversary knows that they're in a honeypot, they will disconnect immediately and you'll lose out on that threat intelligence. They might circumvent it in their attack paths or they could use it as a machine itself as a pivot and get to your other internal systems. This isn't a new consideration and researchers have looked into this in the past. looking at internetwide scanning and how they can fingerprint honey pots from the outside in. Tools such as Honey Score by Showdown can do this automatically for you via

their API. It will give you a score from 0 to 10 depending on the likelihood of that machine being a honeypot. This is what I have hypothesized in my research. It's not just what the machine looks like on the outside, but it's what it looks like on the inside as well, which is just as telling that the machine is not quite real. And this is where we get into wear and tear.

Wear and tear is a term that is used to describe the inevitable aging of a machine through normal system day-to-day use. Think about how you use your computers at home. For me personally, I use my desktop as a dumping ground for all sorts of rubbish. My documents is filled with random things I've downloaded and my DNS cache will be filled with various entries. This is the wear and tear. This is the human element on the machine that that differentiates it from a spotless sandbox or a clean system which could then indicate that it's a honeypot. It's very similar to anti- sandboxing techniques that we already know malware uses within their scripts and within their attack paths.

So we know that malware will check the cursor movements. It will check if the keyboard is connected. It might check to see if how many files have been downloaded. But wear and tear will take this a step further. It doesn't just look at what the system looks like as of now, but it will look at the history of it. What did it look like a week ago, a month ago, a year ago? This is what I looked at in my research. I wanted to see whether the wear and tear on a honeypot could reveal its true nature and could completely remove the deceit that we want to play against our attackers. So what did I do? I deployed the SANS

internet storm center dshield honeypot and in AWS EC2 instance. As we discussed earlier, Dshield is a medium interaction honeypot. So, it's emulating the honeypot through a Python script. There's no real physical infrastructure being used. It uses the Cowry Honeypot to emulate SSH and TNET as well as the Debian file system. Cowry can be deployed independently, but Dshield will orchestrate that as long as as alongside Dshield's own HTTP web server, honeypot. I deployed this in the cloud for 30 days and I logged every single interaction with the machine, every single file that was uploaded, every single command that was run and I investigated those logs to see where I could find evidence of wear and tear being used to identify this

machine. I also probed the machine myself as if I were an attacker to understand where on it makes it look really suspicious with this wear and tear in mind. So what did I find? To start with, I want to share with you the SIS log. So this is a a screenshot of what the honeypot looks like if you were an attacker interfacing with it. As you can see, there's no file or directory. SIS log is a fantastic resource for wear and tear because it will show all of those process events, user events, application events that is logged across many years. The fact that it isn't here is highly suspicious and I think we can all agree

should not be right at all. I've just got an example here of what it looks like on a real Debian machine. I used my Cali box just for ease. And as you can see the contrast is pretty stark. It should be filled with all kinds of junk, all kinds of mess that that will be generated through system use. Similarly to sis log, I looked at temp directory. This is a little bit better because at least it's there. We can ed into it. However, there's nothing in there. This should naturally be generating as we use our machine. As we go through user files, we won't really be interacting with it. It will just naturally be populating. The fact that

there's nothing in there when, as we can see on my Cali machine that it should be full of stuff is again a major red flag that this machine isn't real.

We get a bit better now with uptime. So, as you can see, it says 22 minutes, one user logged in. Looks pretty plausible. And again, when you compare it to what it looks like on the Cali machine, I think this is quite a convincing indicator that the machine is is real, at least to an extent. However, when we compare it to the running processes, we can see that analyzing the timestamps, this machine has been running since July 2022. Now, I took this screenshot in summer of 2025. So, 3 years this machine has been running, hasn't been towed off, haven't hasn't been restarted. My immediate thought was, great, it hasn't been patched, which means there's lots of vulnerabilities, lots of honey

for our adversary to play around with, and that might entice them to stick around longer, and we can then get more intel on them. But remember our uptime command, 22 minutes. 22 minutes versus 3 years. Any eagle-eyed adversary would notice that difference and would disconnect immediately, note it down as this is a honeypot, and get out of there. Apart from the time stamp, the running processes is highly detailed and unless you notice that timestamp difference, you probably would think this is a real machine just with a first glance. So, it's not a terrible wear and tear artifact, but does need improving. Next is tree. Tree should be native to Debian. Um, so the fact that it's not

there might be a bit of a red flag for our adversary, but for me, it's more than just that. tree will show everything that's in the file and everything that isn't in the file system. So our SIS log which isn't there, tree will will show that that's not configured. Any user files in the home directory which you'd expect to see populating as our users naturally using their machine, it will show are there or aren't there. So for me, this should be configured so I can get a quick overview and make it look busy and and messy as as we would expect. And then yeah, here's just what it should look like. And then finally, there's some

networking inconsistencies. IP neighbor command says it's not found when we should see some entries in there at least.

Overall, I've examined 14 different artifacts across system, disk, and networking, and I tested them all and I assessed how plausible they were as a wear and tear artifact. Overall, 78% weren't adequately configured. And my baseline for that is, does the file exist? Is the command configured? And do both of those things look plausible and look convincing enough. and 78% of that doesn't fit into that category. So, we know that Dshield isn't very convincing from the attacker's point of view. But are adversaries actually looking for wear and tear in their attack paths? To answer this question, I pulled the frequency of any any probing of a wear and tear artifact within the log and then plotted it by their session.

There are some things to pull out from here. Firstly, temp and home. So 108 sessions have explored temp and 63 [laughter] have explored home. As we saw earlier, temp should contain all those kind of naturally occurring files as we use the machine. It didn't have anything in it. So attackers are checking this seeing there's nothing in there. Seeing that it's spotless, they probably then exit again with home. This is then our user directories, the folders that us as users will create and use, documents, spreadsheets etc. etc. With this being examined, we can see that attackers are then looking for that user interaction. We can see that they're they're looking to see what us as humans are creating on that machine.

Equally, although it's a small frequency, 15 sessions examined log, we know that this log doesn't exist. The file folder doesn't exist. And so despite it being quite a low frequency, it's very suspicious for the adversary to then go into that, see that it's not there, and we can assume that this number is just going to go up as adversaries use wear and tear more and more. There's a couple of other little bonus giveaways which aren't necessarily wear and tear, but are kind of obvious that it is a honeypot. So firstly, I did a end end map detection scan and the HTTP web server that's running on a honeypot is revealed to be version 3.2.3. Those Apache fans out there will know

that the current version is 2.4.68. And so somehow this machine is running in the future. [laughter] If I was adversary, I would be getting out of here pretty quick. Again looking at an NMAP port scan, you can see that D shield incorrectly assigned some of the ports as Rockwell CSP2 and NDNFSD. So this is a legacy scarder system. And remember our honeypot is running in the cloud. Legacy scarder and cloud. And then there's also a network file demon. So we know that there's MLA services running on the machine. Immediate this is a honeypot. And then finally the user and the group. So you can see that the group is dimwit. This has changed. However, it's

obviously a bit of a joke at the attackers. But on a more serious note, the user Phil, so this is known to be cowery and subsequently dshield. And it's even in the documentation to say our default user is Phil. Please change this. So if you don't go and change that, it's a fairly fairly high confidence artifact that this is a honeypot. So to conclude, honeypotss aren't as good as they are convincing and dshield isn't very convincing. No wonder the group is called diminwear. We've got a Debian system that's running what appears to be a legacy scarda system in the cloud with a future Apache version. And there's a halffinish file system. From the logs, we can see that

adversaries are checking wear and tear artifacts. Although it's quite a small amount of sessions that are doing it at the moment, I predict that this number is just going to increase as they start to consider not just what the current system looks like, but his past use as well, going back as far as they can. We need to do more than complete the file system on Dshield. We need to set a narrative for what we want the honeypot to look like. We need that history and we need it to be convincing. So, we need to tailor every single element on that machine to fit the story we want to tell. We need to make the machine messy. You

need to throw a bit of pocket litter in there, make it look used, make it look lived in. And then hopefully with all of that, it will keep our adversaries buzzing around the hive that little bit longer. Thank you so much for coming. We've got a few more moments for some questions. ANY [applause] QUESTIONS? I can throw a microphone around if we have the microphone. >> Any questions? Any guess?

>> Thank you. Um, I was wondering instead of making your system look lived in by a user, could you make it look like it's running a service so it looks like it's most used on the airport except for when a client is talking to? >> Yeah, absolutely. Whatever you want it to be cuz it will depend on where you put it in your network, what you want the adversary to think when they connect to it. And so if it's a machine that you don't want it to look like it's got a user constantly interacting with it, you wouldn't put that in there. But you still want that any if there's any logs occurring on the machine. You still want

that populated. You still want temp files being created. The process is running. So even if you don't want it to look lived in, you still want it to look real and as if there is something going on rather than just a kind of empty halffinish shell almost. That answers your question. >> Thank you. >> Um what kind of config configuration options does give you for it was mentioned briefly on the last slide but is there is there enough there or is it like >> so you can go into the when you deploy Dshield you can go in to the back end and set a the answer to the command. So you can tailor what the PS command does,

for example, and you can put that to be whatever you want. So it would be manually going in and saying, "Okay, PS is doing this. I want it to do this." And then set that to fit the story you want to tell with the machine. At the moment, there isn't, to my knowledge, a tool that will do that for you. It's just then on the developer, uh, the honeypot admin to to configure that. Um but that would be where we want to go in the future is to provide carry and subsequently dshield with more junk more more in it to begin with so it makes that job a little bit easier configuring it >> questions.

Yeah. So you said things like looking at a tetra seeing this empty and then you presumed that they would exit out they were able to get those show that they did ex out that they might be using a script that at the end which will say >> this is likely to be a honey then that slightly changes just the way we look at it or it's a manual thing going >> around things or >> yeah great question and I did have considered that I analyzed the second to last command in my data set. I assumed that the last command would be exit and then the second to last command would be the reason that I exited. However, it

didn't give me any particular wear and tear. Looking at the logs as a whole, it was a lot of scripting going on. There was only a few command there was only a few sessions that I could fairly accurately attribute to a human based on the time in between the commands taken and and the style of the commands being executed. But from the second to last command as why didn't they include it today a for time and b it didn't tell me very much as I think it would the buildup of evidence across it they would check in the scripts the different artifacts check the current system use and then a couple of the wear and tear as we saw

not as much as the current system >> and then that buildup of evidence as they go through a point in their script they would then deviate if it was a botnet they wouldn't care they just try and deploy their their um program and then get out of there. Um cuz for them it doesn't really matter. But for a lot of the scripts it was trekking lots and then it's not necessarily the second to last which was the reason they exited. It was that buildup of evidence across their script. If we're consistently seeing threat actors exiting systems that lack of wear and tear, um [clears throat] could we look to remove wear and tear from our

legitimate systems to try and uh make adversaries who have managed to get that far more likely to self disconnect and therefore not cause any damage. >> That's very interesting. I haven't really thought about that. I suppose yes, you would. But then if you're just a normal day-to-day user, you would need something to be clearing your sis log and clearing your temp and all this sort of thing. But it then could be kind of like a double trick where you have real machines with clear sys log. The episode then go this is half empty even though there's real stuff on it. So I suppose you could use that as as a tactic. So double bluff is almost

time for one more. Any more questions? Is there an alter alternative to dshield that you've used at all? [clears throat] >> I haven't I've deployed cowerry by itself. So that's just the ssh tet and debian and then had a poke around with that myself. I haven't looked at too many other honeypotss. There's ones that I want to go in and look at such as compot which is a um IoT honeypot. So that would be really interesting to see the difference between the wear and tear on what's a normal machining and what's IoT. But that not not yet to answer your question, but something that I would like to take forward. Cool. Cool. That's pretty much what time. Let's give

Milda a really good