So I was just recently hired as a Heikzoch Revitalization Coordinator for our nation, and our goal is to have Heikzoch thriving for all Heikzoch. Sadly, we are down to two percent speakers. That's why there's an urgency for us to look at other methods, other ways to revitalize our language. We are starting off with the silent speakers first, and the silent speakers are those that understand the language, but don't speak it. We're going to do a three-month pilot project with them starting from March to June, so three months, and it'll be three hours a day, five days a week. In September, the plan is to have immersion for the babies, and then we're hoping to have, in the future, one for the parents, so that we can fill the intergenerational gap, because in Bella Bella, as you know, the language is only being taught at the school half an hour a day in 45 minutes, and they also have bilingual happening in the daycare, and in the Sassum House, which is a zero to six programs, and they're just starting to introduce it in the Child and Family Services programs at Kehla. We're hoping to partner with SFU again. We have some students that still need to finish a few courses to get their language proficiency certificate, but we're also looking at having a course where students are immersed in the language for 900 to 1200 hours a year, and we're hoping to do that in three consecutive years. I've also spoke with SFU, with UBC, and Tribal Council has already given them permission to teach Kehla, but it is not immersion based. It's just a language course. We haven't started any of our programs yet, but with the 15 years of experience that I've had in language revitalization, it definitely has given me the tools that I need, and ideas, and the direction that we should go. We definitely need to in order to have immersion, we need to make language learning fun, and we've learned different methodologies like Dr. Gray morning methodology, which is accelerated language transition. We've also learned TPR, which is Total Physical Response. It's action and command based, and I've also used Kagan, which is cooperative learning, where the students learn together and to teach your guides a process. I've used that as well to for language, and it's another fun game-based learning where the students really enjoy it. One of the other methodologies we're looking at is where your keys, and it's based on sign language. Through my experience at the school, I'll be using the Total Physical Response and Dr. Gray morning methodology to help with teaching the silent speakers, and I'll also be using a lot of the curriculum that I created to help teach the language. We recognize that a lot of our people went through a lot of trauma around our language when they're in residential school. We understand that we definitely have to pay attention to that and give them an opportunity to to heal, and our idea with that was to use our own traditional healing practices with cedar bough, river cleansing, smudging, but we also have a cognitive behavioral therapist in Bella Bella, which would really benefit them if they choose to do that as well, and what that would do is help them to overcome and revert the anxiety so that they'll be able to rise above it and be able to learn and feel safe with language again. The program always speaks for itself, but definitely we intend to have assessments, you know, different forms of assessment. I haven't really determined that yet, but we have learned some assessment through Chase's, which is a successful immersion program here in B.C. I'm really looking forward to being a part of a community team of language stakeholders who are willing to work together to ensure that our language is not just going to survive but to thrive.  It's vital to our identity as Heikzuch.


And I have to make an announcement, this talk is just a honeypot. You can all go now. Ah, they don't believe me, you see? Okay, who of you has a honeypot? One, two, three. Can I have a little bit more lights on the audience please so I can see some? Thank you. Couple of you have honeypots running and do you think they are secure? Do you think they can't be used against you? Think again. Dean Sisman and Ed Marcher will now present you how honeypots can be deceived and actually be used against you. A warm welcome please. Okay, hello everyone. Unfortunately for us, Gadi had to miss this talk so we will make do without him even though he brings a lot of weight to every talk. If he was here you would realize it's funny because he's fat but never mind. Okay, so what essentially are we gonna talk about? What we're gonna do is show you how a honeypot can be used for your advantage but then how it's been used before and how we can improve on it and what disadvantages it brings when it's being used, right? Okay, so just a disclaimer. This is a technical talk, we're gonna go into a lot of technical material but as you'll see, which is a surprising fact, there's very little knowledge required in order to circumvent a lot of the honeypots that's very popular today so the technology here is gonna be pretty basic and pretty fundamental. And this is about us, we all work together at Symmetria, all pretty, you know, been doing this for many, many years and this is a big part of our lives and part of the community, obviously.  It's this weird buzzword that you would imagine like a lawyer using and not really understanding what it means. What we're talking about is we would like to be able to take the attacker's behavior and his methodology and be able to impact it because if we're able to impact that, we're able to gain detection, mitigation, you know, prevention, a lot of very interesting stuff that deception gives us as soon as we're able to influence the attacker's decision-making process. Right, so a lot of people have been advancing this field a lot, even a lot of German people Fred Cohen's deception toolkit was the first thing that ever came out that talked about deception, Les Spitzner and the Honey Net Project have been doing a very amazing work and they've really advanced this field a lot over the last few decades. But what we will be talking about is how the perception of what honey pots can do for us today is very different than what people usually perceive that they do. So what's the difference between an attack and an attacker, right? An attack is a specific piece of technology that changes very dynamically and is very hard to capture and that's what a lot of the intrusion detection tools nowadays are trying to figure out how to detect and it's very difficult, everybody knows about the false positive problem and everything, but the attackers usually have a very definitive method of how they work, right? There's the first beach head which gets through spear fishing, then you do lateral movement in the network, you gain domain or admin credentials and then you look for the intelligence you're looking for, right? And this is very hard to change or very hard to dynamically do differently. And this is sort of how the attacker feels like when he's inside your network, right? There's this fog of war where I've infiltrated a network and now I wanna get to the information I'm looking for but I have no idea what's going on and this is one of the only advantages the defenders have over an attacker and that is that they know their network much, much better than the attacker does. So why not use that advantage for your own benefit, right? And if we look at this in a more strategic way, in the US Army, in the Air Force, they came up with this methodology called the Uda loop and Uda means observe, orient, decide and act and this is like a strategic algorithm for tactical situations. And if you can influence the observation period, then obviously you're able to influence the entire behavior of the attacker, right? So what we basically wanna do is this, right? Even though this is a bad metaphor because the Wiley coyote usually loses to the road runner but this is essentially what deception is and what honeypots have been trying to implement, right? So this could actually be a very big change if we're able to deceive attackers, right? Because deceiving an attacker might be something that's very economically cheap but very expensive for the attacker, which is something we don't have today. And when we're talking about what's the elements of doing cyber deception, it all comes down to something very basic which is the decoy, which is this one unit of deception in a digital network, right? Okay, so one of the advantages of doing this is that when attacker gets to a decoy and attacks it, by definition, nobody knows about this decoy, nobody should be accessing it, nobody should be talking to it. We know that whoever is talking to it on our network is an attacker or some sort of thread that's looking around and doing stuff you shouldn't be doing. And this gives you a very clear cut knowledge about what's going on in your network and who's trying to do stuff they shouldn't be doing, right? And specifically, if you get any new code execution, ran, being run on that decoy, you know for 100% that that new code is an attack, right? Okay, so now we're gonna go into some descriptions. The most popular honeypots out there are what people call low interaction honeypots. And we'll go into defining what that is pretty soon, but what they're very useful for is malware, known malware, automatic exploitation, botnet scanning and all that sort of stuff, but they are very limited. And the reason for that is they do emulation of stuff on the network, right? They don't do the actual stuff, they just simulate it. And then when an attacker reaches it, there's a risk for the defender. And that risk is that if the defender doesn't deceive the attacker in 100%, if an attacker is aware of being deceived, he can use that against the defender, right? If you know where a honeypot is deployed in a network and you wanna attack that network, what you'll be doing is just, you know, d-dossing that honeypot because the alerts from that will take all the attention of the defender and then you can go about it in whichever way you want, right? Okay, so what's the difference between low interaction and high interaction honeypots? So low interaction is, like we said, is just a simulation of some network protocol. High interaction honeypots are the actual machine themselves that the attacker can actually successfully attack, right? Because we want him to be able to do whatever he's doing and feel like it's a real machine. And now for a little understanding and terminology, is being able to fingerprint a honeypot, is that a vulnerability? Well, it's an interesting question because for example, Tor has a lot of code execution vulnerabilities. These are pretty obviously vulnerabilities, but in Tor what we're actually interested in finding is the user's original IP, right? Because that's the objective of Tor. So for example, if you could find the specific IP of a Tor user, is that considered a vulnerability? Well, we feel it is, but terminology here is pretty gray area, right? Okay, so when we're talking about low interaction honeypots, those are just simulations of network services, right? Could be SMB, SMTP, DNS, all the popular stuff that hackers are looking for and wanting to exploit. It's pretty easy, just basically what happens is people write some sort of script that implements the protocol's behavior and the way it answers queries and everything, and then we can see who's talking to us and that way we can monitor what's intact or what's not. High interaction honeypots are the actual systems themselves, so for example, if I'm trying to show an SMTP server, what I'll be doing is actually have a real SMTP server running, and the difference is that this is much harder to monitor, right? For example, if you put a Windows machine and try to monitor all the SMB traffic to it on the network, it's insanity, right? Because the amount of noise is incredible, and then we again go back to the regular problem of false positives and how to differentiate noise from stuff that isn't noise. Okay, so when we started this thing, we tried and found out who else knows how to find honeypots in networks, and Shodan has this interesting website, which is called Honey Score. In Honey Score, you give it an IP and then it tells you if it's a honeypot or not, and we started playing around with this and we couldn't get it to say something is a honeypot, right? So we actually created online public-facing IPs with honeypots and gave it the IP and it couldn't detect that it's a honeypot. So we tried and figure out what does it actually detect, and then we found out about something called Kanpot, right? So Kanpot is a SCADA type honeypot. What it does is it looks like a SCADA machine, but it only implements a very small part of the protocol, and what happens, one of the Shodan guys did some research into how Kanpot works, and he found out that every Kanpot implementation out there has the same name, which is Mauser Factory, right? Which is not very deceiving. But then somebody figured out that that's the default and people made it configurable so you can change it to whatever you want, and then there was another guy online called Sean Mertiger, who found out that they all have the same serial number, and this is also not configurable.  And then when we tried and took one of those IPs into Shodan, we finally got it to recognize that it's a honeypot, right? So other people have been trying to attempt this because it gives a lot of value, but it doesn't really work for most of the honeypots out there. Okay. Okay, somebody in the audience asked me to talk slowly, so I'll try. Thank you. Okay, so what we will be doing is going through each project of... What we will be doing is going through a lot of the popular honeypot projects from the most simple implemented ones, to the most complex ones, and show how each gives you another layer of deception, but how we use that layer and circumvent it or use it to our advantage, right? So we start with artillery. Artillery is a pretty cool project. What it does, it's very popular. You just run it on a system, and what happens is it opens up all the ports that are closed that look like something that's interesting to an attacker, right? So SMTP, DNS, HTTP, whatever, and whenever somebody is trying to access one of those ports, what happens is this, right? So it just gives you random information when you're trying to access one of the ports that artillery set up, and then it blocks you away. The way it blocks you is by putting in a rule in the IP tables for your IP, right? So the thinking is I'm a defending in a network, right? And I wanna do a honeypot on all my machines. I run artillery, and then if somebody's trying to exploit stuff against, I don't know, SMTP servers, they'll hit one of my machines, and then they'll get blocked because the IP tables rule blocks it, right? Obviously, this doesn't look very deceiving, right? If I'm an attacker in a network and I'm trying to talk to some sort of port, this doesn't look like SMTP. And like I said, what it does, it just gives you random data, no real deception being employed, but it blocks the IP that it sees, right? This is very dangerous. The reason for that is if that network doesn't have any protection against network spoofing, you can spoof any IP you want, and artillery will block it. The reason being is you can just send it two packets with the source IP change, and it doesn't try and connect back to the original source and see if they're true, right? So just by sending two packets, you can make the machine that's running artillery, block any IP you want, and this even works for the gateway, right? So you can just make it drop from the network completely and not have any network connectivity. Right? So what can we learn from artillery's work is that if there's a port and nobody should be touching it and somebody is touching it, then that's an indicator of attacker activity. Right? So how does... So now let's switch our hats and think as attackers. Now that we know that artillery is out there, what do we do? So now we need to consider that every place we're connecting to might be a trap and we need to check if it's actually real, right? Okay. And next we go to bear trap. So bear trap actually implements some of the services. It's broadcasting and tries to make sense of it. The biggest one it's trying to implement is FTP, right? And when you talk to bear trap on FTP, you get this banner. Now, if you know bear trap is a honeypot, getting this banner is sort of shooting yourself in the foot, right? It should have just said, hi, this is a honeypot, right? So this is bad. But actually the banner is configurable so you can change it to do anything you want, but getting this as the default is already pretty, not considering how to actually really deceive an attacker. So another thing we tried to find out that isn't configurable and ultimately detects bear trap is that anything you give as an FTP protocol command just returns five, three, zero, okay? This makes no sense in the definition of the protocol. So no other service in the world should be acting this way and this is a clear cut way of detecting bear trap, right? By definition, the protocol, when you give it a user command, it has to return a specific answer and returning five, three, zero doesn't make any sense because it's not a specific answer that's expected. So this detects bear trap very effectively, right? And if we look at other FTP servers like VS FTPD, which is very popular, what happens when you ask for certain stuff, it replies with a certain reply, right? Cool, so bear trap also suffers from the same problem with IP spoofing as artillery does the exact same thing. As soon as it sees somebody connecting to it, it asks for the user and password. As soon as that is passed on, it blocks you through an IP tables rule and of course it doesn't check anything. So if you IP spoof, you can also drop that machine completely from the network, right? So what do we learn from bear traps work is that if you implement the service, it's much, much smarter, much more deceiving than attacker, but now if we're looking at this from an attacker's perspective, I should be looking for indicators of deception, right? So now attackers should be looking for the stuff that would make it obvious that this is a honeypot, like that bear trap part in the banner, right? Okay, so now we get to HoneyD. HoneyD is probably the most well-known honeypot. What it is actually, it's much more of a platform than an actual honeypot. And this is pretty cool because it makes you able to write different things into HoneyD. So essentially you can create different types of network services and for each network service, you put in a script that implements that protocol, right? But the problem is that HoneyD comes with a lot of default protocol scripts which everybody use because you don't wanna be, you know, replicating very well-known protocols like FTP or SMTP or DNS or SSH or whatever. And in these protocols, you can find a lot of very easy ways to fingerprint HoneyD, right? So first of all, when you use HoneyD for something that resembles an IIS server, there's this command on the top that HoneyD tries to implement because it's a way that a lot of automatic online scanning tools use to try and find ways of getting dear lists from IIS servers. This was an old vulnerability in IIS. And what happens is it returns the exact same reply every time and if you look at the modification time on those files, this is a server that nobody has been, nobody has touched in over 15 years, right? So first of all, this is not very believable and secondly, very easy to fingerprint in order to detect HoneyD, right? So if we look at the other service protocols, there's a lot of other ways to fingerprint. For example, the FTP doesn't support the DELE command, which lets you delete files. I'm assuming they did this on purpose because it's very scary to enable deletion of files on a HoneyPod because if you have any sort of bug in that, you're really risking your system. Secondly, the SSH script for some reason doesn't do anything, it just opens up the port and doesn't reply at all. So that's another way of detecting it. And in any case, it will be very obvious to the attacker that this is HoneyD, right? So how would I go about fixing that? For example, in IIS, I would just return an empty DEAR list and you have to really realize that there's a lot of information there. You have to make it believable. Both the timestamps, the byte counts, and the volume serial number, you should randomize them periodically. That's the only way to make it look like it's actually real. And what can we learn from HoneyD's work is that if we implement the service, we have to give no obvious indications.  But now from an attacker's perspective is now that every service that we're talking to, we should be looking if it's partially implemented or actually really implemented. So next up is Nova. Nova is pretty cool. What it does is just essentially use HoneyD in a more solution type perspective. So it gives you this very cool user interface where you can create machines and look at the logs. And they have pre-configurations so instead of just running specific scripts for specific ports, it actually does a full-blown machine so it can create a Windows machine, a Linux machine, and whatever. And it looks like actual real machines on a network. The problem is when you create a Windows machine, the default Windows config has no NetBIOS service script. Now, NetBIOS is a very old protocol which exists on every Windows machine. And there's a lot of usage in the networks for Windows machines using NetBIOS for network discovery. So what happens is what Nova does in its basic configuration, its default configuration, is create an open port for NetBIOS and allow connections to it, but it doesn't implement the service at all. So there's this open port which you can talk to, but it never gives you any answer. This is a situation that would never happen on a Windows machine. The only two options is either it would talk to you or if it's firewalled off, then the port would seem closed. So this is something that ClearCuts shows that this is a Nova Windows machine. A possible fix for this is maybe including the latest version of HoneyD, which also has the NetBIOS script implemented or just not opening it so it looks like it's firewalled. So what can we learn from Nova's work is that we should implement the service completely, and now from an attacker's perspective, we learned that we should look at the set of services completely, make it seem like it's one whole machine and then realize if it makes sense. Okay, now for Kipo. So Kipo is pretty cool. Kipo is a medium interaction SSH Honeypot, which means it actually gives you an SSH shell which you can use, but this is only partially implemented, of course, because it's being monitored. So there's been a lot of research over the years in how to detect SSH. One of the ways is that people have been talking about is obviously like we've been discussing, a lot of the commands aren't implemented, but one of the commands that is implemented is WGIT. The reason WGIT is implemented is because when an attacker accesses that SSH Honeypot, you want him to be able to download his tools, his malware and stuff he wants to run on the machine. So they're actually implementing WGIT, and this is a pretty big issue because this could be used for DDoS-ing other machines through the SSH Honeypot. It could be used to port scan other parts of the network and basically you're getting your own relay against the web for everything on HTTP that you can use for yourself. Sorry, and this is a big problem, right? Another thing that people have done is they look at how Kipo does the SSH authentication, and as it turns out, this is a part from Kipo's source code. This is a fingerprinting problem that's been fixed already. What it does is it gives you, when you ask it which protocol do you want to use, it just says I support everything, right? And this doesn't work in the way that most or all of the SSH key exchange mechanism works, right? So this is very clear-cut recognizing Kipo. And after all those fixes, we were interested in looking for something that even after all that still identifies Kipo. So we found a few things.  The only difference that it does is it changes the name of the machine that you chose in your configuration. Now, this is pretty cool because it gives the compile time of the kernel, this is a pretty unique identifier. So if you use the string and look it up on Google, what you get is a lot of people who are IT admins who are connecting to stuff on their network and they're saying, guys, this is an SSH machine running on my network and it's acting really weird. I have no idea what this is. Here's the username if you guys can figure out what's wrong with it, which is pretty funny. So a possible fix for this issue is either give the actual machine's kernel timestamp, which Kipo is running on, or just randomize it from a logical set. And what can we learn from Kipo's work is that now the honeypot not only gives you indication of the attacker's activity, it also tries to collect information from him. And this is pretty cool because the more information we get from the attacker that we can say this is the attacker's tool set or the stuff he's doing, we can create stronger mitigation, because if there's an APT that's attacking us and they put the sample on that SSH Kipo machine and we block that sample, now we gain some sort of mitigation. And if we look at an attacker's perspective, now not only are we in danger of being detected, now we're in danger of being caught or mitigated against that network we're attacking. Okay, and the next step is Dionia. Dionia is a very impressive project. If I'll go ahead and read the description, Dionia's intention is to trap malware exploiting vulnerabilities exposed by services offered to a network. The ultimate goal is gaining a copy of the malware. This is exactly what we talked about. The ultimate goal of deception against attackers is gaining their tools, right? Gaining the malware, gaining the CNC server, gaining the exploit, the credentials, whatever, whatever, right? And this will in the end lead to effective mitigation which is very, you know, the holy grail of security. So there used to be a very easy way of detecting Dionia. If you would scan Dionia with an NMAP, you would get an MSQL server that says, I'm a Dionia Honeypot MSQL server. Again, this is a problem since it's obvious. And this is not a very good way of deceiving attackers. And this has been fixed in the past. It doesn't do that today. But something very interesting we realized when we were researching Dionia and we talked to Marcus, the maintainer of the project, who's a very awesome guy and they're doing a lot of very cool work. Somebody sent, Marcus, he told them, when I'm working with Dionia, there's a lot of stuff that doesn't behave like the usual thing I would think is behind the Honeypot would behave, right? There's a lot of stuff that behave weird and people could detect the Honeypot through that. And then he says, by the end, which is something interesting, well, I'm totally aware of the problems you point out, but besides from these three are just the tip of the iceberg, there is very little I can do about it. And this basically means that all the people maintaining the Honeypot different projects realize that this will never be able to deceive an advanced attacker. Somebody who's aware of, he might be interacting with a Honeypot will always have ways of detecting low interaction type Honeypots, right? So for example, in Dionia, something new that we discovered is that when you run the HTTPS service in Dionia, it's signed by a certificate, and that certificate's issuer is Dionia's URL, which is not very deceiving, right? Secondly, if you use the FTP service, it allows you to log in using any username and password combination. I have yet to see an authentication mechanism that allows two different passwords for the same user, right, so that's another way of detecting it. And obviously, another way is that FTP doesn't implement the DELE command just like HoneyD, right? So there's a lot of way of detecting Dionia. What can we learn from Dionia's work is that they try and make their services exploitable to known exploits. So for example, they have a way of capturing Conficker and Blaster and all these really popular worms that exploit different services, and what they do is as soon as the attack happens against the service, they capture whatever code is being executed. And now, this affects an attacker by realizing if I'm exploiting a new machine on the network, my, you know, old MS0867 Conficker exploit, which I'm running and then executing my own malware through might cause me to lose my malware because it'll be captured by Dionia. Right, next up is Glasssoft, which is a web app type honeypot, right? So what Glasssoft tries to do is look like a web application for different kinds of languages and just see whoever is trying to do web type attacks against it, right? When you set up Glasssoft and you look at the default page, this is what it looks like. And it's actually, Glasssoft is very configurable and allows you to load in almost any type of file system or web application that you want, but if you run it defaultly, it just gives you a very weird page that not a lot of people change, right? And if we look at the bottom of it, there's this signature, which doesn't change. Most of the text here is just random from a list of a dictionary, but if we look at the bottom, there is a footer that says this is a really great entry, right, and this doesn't change across pages. So I just took that string and looked it up on Google and I found some really interesting websites which I won't reveal here, but one of the top 500 websites had this in his subdomain, right? So assuming it's like a really popular website, if I go to one of the subdomains.reallyfamouswebsite.com, this is the page you get, right? Which is very interesting because they're deploying honeypots, but not in a very smart way. So they're very aware of security, but they're not aware that deploying those honeypots just creates less deception for the attacker, not more. So how does Glastoff work? What it does is any sort of web interaction against it, it logs it and for specific stuff, it gives alerts and you can actually create any sort of file system within it because it implements directory traversal exploit, right? So if you do, for example, if you go and type in the address for the Glastoff and then do slash and then dot, dot, slash, dot, dot, slash, dot, dot, slash, etcshadow, it actually gives a file that you can configure and put in within etcshadow, right? And this is the default one and I would say this is a way to fingerprint Glastoff because this is configurable, I don't wanna be able to say that and I wanna try to find a way to fingerprint Glastoff without the user being able to change it, right? So something that you figure out is that if this is a Linux machine that gives you etcshadow from the permissions that you get and how Linux is built, you should be also able to access slash proc, right? And if you're able to access slash proc, this is something that's very hard to simulate for the people who are configuring that Glastoff implementation, right? Because first of all, you have to put something in the file system that Glastoff will give as an answer for slash proc. And secondly, once people have realized that this gives the actual answer, it has to fit the actual process running Glastoff because that process is within slash proc, right? So for example, if I would go ahead and look at all slash proc and all the slash PIDs and slash S maps, I could find Glastoff's own memory statistics, right? And I could use this to see if this is actually correlating to what I'm seeing on the website by doing more HTTP requests and stuff like that. So no matter what, I'm able to realize this is not a real server unless there's an actual real server behind us. So this is a way to always detect Glastoff without doing any configurable stuff. And the way I would fix this is just return permission denied on slash proc, but this again doesn't make sense in a Linux sort of way. So it's not an actual real fix. What can we learn from Glastoff work is that Glastoff is the first one that lets you actually load the file system for that machine. So it's not only giving you network type services to deceive the attacker, also the actual machine's content, right? And for an attacker, this risks you in attribution, right? Because you have an online connection against that machine and you're putting in stuff into the file system which you are interested in. So for example, the fender could put different types of files and see which files are being taken and where they are taken to, right? And the last one is KF Sensor. Now KF Sensor is interesting because it's an actual product. It's a honeypaw for Windows. It's not open source, it actually costs money. It's been around for, I don't know, I think like more than 10 years. If you go to its website, it looks like AOL in the year 2000, but actually a lot of people are actually buying and using it and it works somewhat well. It gives you this very large graphical interface which you can use and configure almost every single type of service on a Windows machine that you'll want. But it's pretty weird for a lot of reasons. When you do the default configuration, it gives you alerts on broadcast requests. So this is pretty bad because essentially what it means is you'll be getting alerts all the time automatically as soon as you put it into the network and the default configuration for the software also makes this siren sound as soon as there's an alert. So whenever we were working with it in our research, you would just set it up and you would just hear this ooh, ooh, ooh, all the time going on. So it gave us a lot of... It was awful, awful. I'll say it was horrible. Yeah, so it gave us a lot of humorous moments during our research. So how do you identify KF Sensor? So if you set up the HTTP service, it gives you this default website which you can just, again, Google up online for the search code and then you find a lot of different KF Sensor deployments because there's the default website that nobody else has. When enabling HTTPS, the port is open but it doesn't implement the service at all. This is similar to what happened in some of the other examples we've said. And it also has a configurable amount of concurrent connections before it blocks somebody. And then it's vulnerable to what we talked about that bear trap and artillery are vulnerable for. That's if the network doesn't protect from IP spoofing, it just allows you to drop machines from the network as much as you want. Okay, so what can we learn from KF Sensor's work is that even outside the open source ecosystem, the issues are still the same. So this is not something that just comes from being open source projects. This is from any type of low interaction honeypot that's trying to be implemented. Cool, so now after we had all these types of ways of figuring out deployment and how to detect honeypots, we said, let's just look everywhere in the world that honeypots are deployed. Maybe it'll be interesting. And what we did was we used the ZMAP project which is a way of scanning all the internet very quickly and we took one of their scans, daily scans for HTTPS certificate information and we did it for one day. This was for the 14th of July in 2015 and we looked at who would have the Diania certificate which is the, remember Diania.Carnivore.IT, right? And every website that has that as HTTPS is by definition a Diania honeypot, right? So this is the results, not very high resolution. It's very obvious to see that the most honeypots in the world for that day that are Diania is Taiwan, second place is the United States and then all the other countries are pretty much less significant. This is the complete country number deployment. The way we figured out which country belongs to which IP is through regular geolocation IP methods so this hinges on the validity of those methods and there's a few interesting stuff here. For example, you can see a lot of countries you wouldn't expect to have honeypots like Tanzania or Zambia which actually have more Diania honeypots than Russia for example. Other countries which you would think are here are not like Israel, my own country which does a lot of cybersecurity and some interesting countries are here like Iran for example which we will go into shortly. So then we tried and figured out which organizations are hosting these honeypots. The biggest one was there's one Taiwanese ISP that hosted a huge amount of honeypots. I'm thinking just the guy there really loves Diania. He's like, oh my God, every spare IP I have I'll just forward to a Diania machine. I think there's another guy just like him in the United States and one of the universities. I'd love to get those two guys to meet. There'll be an interesting meeting. Another one in Taiwan, another university there and one of the more interesting ones is that there's one of the top cloud providers had 80 honeypots in his network but what's interesting is they publish what IP range is the cloud is in and there's the other IP ranges which are part of the organization that aren't part of the cloud and some of the IPs we saw for honeypots were not in the cloud range. So it's either hiding what's the real cloud ranges of it or it's just honeypots within its corporate network, right? Some specific interesting organizations which we've anonymized. There's a Ministry of Defense one of the European countries an international economic organization one of the US municipal authorities and a South African financial services company which is a pretty random list. I have no idea why but it's interesting to see. Some more organizations, Taiwanese government authority and the computer manufacturer, a Japanese infrastructure project, another Cambodian government authority and there's actually a malware research blog and this is an interesting story. I go into the blog and it hosts mx0. the name of the blog as Diania. So it tried to look like one of its mail servers is Diania and then when I went into the blog itself the guy was talking about how he was capturing malware samples using honeypots he was deploying. So it's pretty funny I thought about doing something and then seeing if he'll blog about it again but then I decided it's a little too much into the blackhead territory. And one of the only organization that we will reveal the Iranian oil company does deployment for Diania. It's actually one of the subdomains for oil.ir. So I guess the guy running the Iranian national oil company really likes cybersecurity and he has Diania deployed in one of its subdomains. So when I saw that the oil.ir website has Diania I said let's go into, I saw that it also serves HTTP not only HTTPS and then I was interested in seeing what I'll get when I'll log into it and guess what I got. So this is the default website for Glassdorf and I said it has Diania on HTTPS and it has Glassdorf on HTTP. Maybe there's some sort of something that packages a lot of honeypots together and then I came across something called the Modern Honey Network. So the Modern Honey Network is an open source project that a company called ThreatStreen does and what it basically does is just packages a lot of different honeypots and scripts into one machine which you can just run, deploy honeypots and then you gain a lot of the default type of configurations of a bunch of honeypots. So lessons learned, right? So these flaws are really easy, really simple to find. They are by design so no low interaction honeypot can avoid having these types of flaws and what we're realizing is if an attacker is aware of deception and he's looking for deception, specifically low interaction honeypots they'll be able to find them and detect them and use them against the defender, right? So what can we do to do this better, right? What would a good way of doing deception look like? So let's just go through every single layer that we did and see what was the cause of the problem, right? So first of all, we need to supply the service itself. Then we need to supply the whole service so implement the entire protocol. Then we need to make the set of services make sense as a complete machine. Then we need to make that service exploitable for non-exploits, right? So the attacker will actually succeed and will gain his malware that's being installed. Then hopefully what we would wanna do is make those services exploitable to non-exploits like O-days and the problem with that is that if you don't know how the O-day works, how do you simulate the way of being exploitable to it, right? And the future fantasy is that the machine is an actual real machine in every way informed for the attacker, right? But this causes the problem of how do we monitor the attacker going into it, right? How do we avoid all the noise that a real machine has? And I made a pyramid of what that looks like. All the stuff, every layer you need to implement in order to have that optimistically best type of honeypot or deception or decoy against an attacker. We'll be releasing code when responsible disclosure is concluded and all the projects can fix all the different issues. And we really just wanna thank all the different people who have been advancing honeypots over the years because you gain a lot of value from running those projects and they took a lot of work. And what this talk was about is bringing that view that it helps against the low level type of attacks but the high level type of APT threats will not only not be deceived by it but can use it against the defender and that's what our talk was generally about. All these people helped us in our research and we thank them a lot. I won't read all the names because it's just a huge list and that's it. So for any question, please come in front of the microphones or you already did, that's nice. Okay, let's start with microphone one. Yes, so hello, thank you. Following your talk, there is a very simple idea I had directly in my mind. What I would do is I would copy some of the mistakes of the honeypots in my real system. That is completely nice. And I would fix some of the problems you have discovered in the honeypots. And this mix I will present to the attacker. I think this will be fun. Okay. Well, I think one thing that is worth noting is that some of the honeypots projects actually had a decent, they provided a decent deception tactics but if you just deploy the default configuration without thinking about it and just thinking, oh, I'm secured then. This is not the good thing to do. So you just need to really think about the consequences of what you're doing when you're deploying in honeypots. A question from the internet. Yeah, so it's more of a remark. So using a default configuration is not exactly the software's flaw.  But changing these default configurations would individualize your honeypot. So the fingerprinting probably wouldn't work, right? Yeah, so this is a true remark. For every project that we've researched, we have a way of detecting it no matter which configuration it has. The reason we've mentioned the default configuration problems is that like we saw, there's a huge amount of people who deploy the default configuration. So optimally, you would want the default configuration to not be that easily detectable, but it's true that you should never count on the default configuration being used or change it to individualize it. That's a very true remark. Microphone 2, please. Wouldn't it be a good idea to use an actual ReAsFTBD and write a module for it to emulate the file system or something like that? Yeah, so basically this is like a trade-off, right? If you do an emulation, you're exposing yourself to the risk of being identified, like we've said, by definition, when you do an emulation, for example, zero-day vulnerabilities will not work. So there's always a way to identify you. If you do the actual real machine, then the problem is how do you differentiate the noise and the regular stuff going on from what an attacker will do? Or for example, how do you even see the attacker's interaction if you don't monitor every part of the protocol, right? So for example, in Kipo during the SSH key exchange, you wouldn't be able to figure out that what he was doing was something malicious because it's something that you don't know is an attacker's interaction versus just, I don't know, like something that's scanning the network or something like that, right? Microphone 4, please. Okay, so what if I turn it around? What if I make my real services look like honeypots and make them give up before trying? That's a very cool idea.  He makes the real machines look like honeypots and that way tries to make attackers not attack them. Yeah, cool idea. Microphone 1, please. Well, I didn't quite understood how I get the attacker to attack my honeypot on my real website. Yeah, so you're talking about what honeypots is trying to solve is if an attacker attacks a machine, you control how now you can detect him and realize that he's an attacker, but you're talking about a problem that's underlying and it's very big, but we didn't discuss it, and that is how do we get the attacker to actually attack that honeypot? So you have to make it look like something interesting. One of the examples we gave for example, that malware researcher's blog, what he did was gave it an interesting subdomain under his domain to make it look like a mail server, right? The mx0.hisdomain, which is a default name for mail servers, but this is the whole other issue that you have to solve when you're doing deception, which is very true. A question from the internet, please. So have you actually broken any honeypots in your research? So we weren't trying to look for code execution-type vulnerabilities. Firstly, because it doesn't give you any sort of value, what we're trying to do more is more like a methodological type of conclusions, so we didn't try, so we don't know if there are or aren't. Microphone number one, please. Just answer to the question, the other gentleman asked, and you said, how do you tell if it's an attacker? One method I'm using is I use, say, actual secure shell, but use a pan module that watches for standard, the top 10,000 standard passwords that people try when they're trying to brute force. You don't get to steal the malware or anything, but if you have that within your network and you see someone trying to log on to your SSH with those passwords, you know you're going to have bad day, you know there's someone in your network, so that's one method of, you would know that was an attack because it's not someone mistyping their password, it's an actual well-known brute force password. Yeah, this is true, this is one of the basic methods of doing high interaction honeypots which are actually real and believable, yeah, cool. Any more questions? Yes, the internet has some more questions. Just one short one, so would it be a good configuration to take one default honeypot and then several individualized ones to make the attacker believe that the individualized ones are more real? Would be interesting. The cool thing about deception is there's so many ways to do it and there's so many ways of, you know, thinking about what's the perception of the attacker and using it against them, so yeah, there's a lot of stuff you could do. And one of the basic things that you need to take into account when you're talking about deception, there's different levels of deception. If, for example, what you're trying to deal with is mainly script kiddies, then you don't need to deploy high interaction honeypots and real machines which is pretty costly. You can just deploy the honeypot that we discussed about just not with the default configuration that is obviously broken. You have another question from the internet? No? Any other questions from the room? No, I close the talk now. Thank you very much. Thank you very much.