BSides Toronto 2019 Harish Ramadoss

So this talk was supposed to be presented by Badrish and myself. Badrish couldn't make it here. So the idea of the talk is to see how do we leverage deception to improve our network defense.

Just a word of caution, I'm no expert at this topic. If you feel something here isn't right, or if you have a better way of doing it, I would love to hear that. A bit of background. When we were looking into deception platforms, we generally saw a lot of commercial platforms out there, and we didn't see anything in the open source space out there. So we guys wrote open source deception platform as well, which I'll be demoing probably later during the talk. So the agenda is to go through deception and its various components. We will then look at deception in depth look at various techniques which we as defenders can apply to detect common TTPs and Then we'll look at some deception strategy and finally

like I said we'll end up with the tool demo So that's a badrish and that's me I'm going to skip this to save time since we only have 25 minutes and So again, deception is nothing new. It's just a fancy way of saying honeypots, right? But I think it's been a buzzword recently with the word deception, but it's just honeypots done well. And honeypots have been used for a long time, but back in the days, or let's say five years back, they were primarily used for research and not for active network defense. And now things have changed. We could implement deception to really improve our detection capabilities.

And decision is not new only to cyber. It was using the warfare also a lot. So this was an inflatable tank which was used by the Australian troops against the German forces in, I think, World War I. This was a fake a mock aircraft and a dummy airbase used by France I believe. So deception has been used a lot in the warfare. We are focusing on deception in cyberspace. So why deception? I mean we already have firewalls, we have AV, we have email security. Why another technology or solution in place? I think one of the things with deception is when you get an alert from a decoy, it's most likely in high accuracy alert, whereas compared to other controls security

controls. I'm not saying they are not they are not required, but there are false positives and let's say I think you get about thousand alerts and two are actionable in that. But when it comes to decoys, even if you get one alert from a decoy, it's most likely an actionable alert. And it is difficult to detect. So if you look at an attacker once he's inside the network, once he's compromised the network, he's sort of blind. He has no idea where he is. He has to enumerate. He has to laterally move to gain access to critical data. So he would have to, uh, do a lot of things in order to reach his end goal. And if we apply our decoys strategically, we

could take advantage of this and cast the attacker probably at a very early stage.

So the idea of deception is to feed attacker with fake information and if they fall for it, they're exposed. And now coming to common deception techniques, we have fake services. So think of fake FTP service, fake SMB service, fake Tomcat server. So fake services is one. Next is client side decoys. Now, how do you catch attacks like LNR poisoning or R poisoning? You could implement a client-side decoy to mimic a client and then detect, let's say, a responder or R poisoning in the network. I'll talk about techniques, so we will cover how does the decoy work specifically in those cases. Next is honey tokens. So think of mimic ads here. How do you detect mimic ads or pass the hash? We can inject

credentials into memory, fake credentials into memory. And let's say if someone an attacker now tries to get memory from LSAS, he would get our fake credentials. And as soon as users that he would be detected. And the last is breadcrumbs. Breadcrumbs is to feed information to the attacker. So he's coming towards you.

Now there are a lot of common misconceptions when it comes to deception in general. Since it was largely used for research some time back, we think that we need special skills to implement deception. But in my opinion, it's the other way around. I think deception is one of the solutions which you can easily place into a network without having specific skill set.

And it is easy to deploy. And the reason I say that is when you deploy a deception solution, you almost have no interruption with your production environment. And organizations don't need to be mature in order to implement deception. And the last the cost aspect, I mean, with, let's say an open source solution like this, you could have an effective, hopefully, deception solution. So that was the theory part. I want to focus more on the TTPs out there, common TTPs, and how do we use that? I mean, how do we use decoys to detect those? So let's start with some very basic things. And one of the things I want to in fact say is, the decoys which we

are implementing, they're not very difficult to implement in terms of technical

in terms of the technical challenges. So the first thing is port scan. Let's say if an attacker is doing port scan, how do you deploy your decoys? Spread different services across your infrastructure. But the problem of deploying various kinds of decoys across the infrastructure is doing at scale. So let's say if you want to have a decoy in every VLAN of yours, different kinds of decoys on every VLAN. Let's say you want to have a Modbus VLAN if you are a SCADA infrastructure, you want to have, let's say, NBNS and a client infrastructure different decoys how do you do it scale so we could use a commercial platform or we could also mean sort of use this tool to deploy decoys across the infrastructure

using a single platform The next thing which I was talking about is a LMR poisoning I think this is a very common attack once an attacker gains for told on the network One it is quite successful and two, it is not very noisy in general. How does the attack work? If there is an incorrect lookup for a name server, the DNS says, I do not know the name, and then we have a broadcast, and the attacker responds back to the broadcast saying, I am that server, give me your net NTLM hash. That's how the attack works, which is very well known. But how could we implement a decoy here? I could now place a decoy on a client, let's say VLAN, and broadcast

LLMNR traffic saying, who has the IP for, let's say, some server or admin PC? And if you get a response back for that broadcast, it's most likely that there is an active attack going on, because you wouldn't see that response in general on your infrastructure. So that's one way of detecting a responder.

So here you could see that when an attacker runs Responder, he sees a lot of poison answers being sent to. And these are the poison answers being sent from a decoy. And what we've done here is we used an MBLOOKUP to do the broadcast. And you could specify different names here.

I think this is one of the most common things. You gain access to a system, use Mimikatz, Again, I mean or any of the tool to gain access to LSS memory and dump credentials This is a very old technique what you can do is you can inject fake credentials into memory There was an article on sans using run as with a net only flag you could Inject credentials in the memory, but it wasn't scalable, but we could use a PowerShell script and and use GPOs to deploy it across your infrastructure. There's a very good article on stealthy bytes on how do we do it with different usernames and different passwords for every PC. The next

attack is Kerberos. I think this is also a great attack vector from an attack point of view because it is not noisy. You can do password brute force offline. And the way the attack works is You as a client go and request for a TGT. You get a TGT back and then you go with the TGT request for a TGS and being any domain user, you can request a TGS and the TGS is encrypted using the service. The service is NTLM hash and the attacker can crack it offline. But now what you can do is So this is the attack sequence. The attack here is looking for SPNs and then requesting a TGS for a particular SPN and then cracking

it offline. You could set up a fake service account and link it to an SPN and set the admin value to one. This makes it more believable and if you see a log entry for I think it's not very clear, but if you see a log entry for 4769 event ID, it means that this service ticket has been requested. So that's for Kerberost. There's an article by Sean Metcalfe on this and how do you do this.

Next is data exfiltration. So let's say now attacker has initial foothold and he is now got access, but his end objective is to probably take the data out from the network, at least in a lot of cases. So what you could do is you could you could put honey files on your network and when an attacker opens, let's say a word document, what would happen is there would be a back end call which would be made to your Web server in this case. So in this case I'm using an example of Word document which is just a bunch of XML files if you extract it and I've put a link to an external server. So

as soon as the attacker opens this there would be a call and we would know that there was some sort of exfiltration happening.

Kendry tokens have a lot of different kind of decoy files which they've done really well and I would encourage you to look at those.

And the next thing is attackers generally look for common I mean or low-hanging fruits right I mean once you get your initial for told you on and now gain privileged access and what do you look for you looks for things like Tomcat Jenkins MS SQL common services and one of the reasons for this is attackers are lazy I mean and and they want to get a quick hold faster and gain access right and You could now deploy all of this as fake services on your environment. If you see a log on any of these, you most likely have someone on the network. So that's an example of a fake Tomcat server, fake FI server, and a fake OAuth account. And OAuth is interesting. So let's say if you

deploy OAuth on your DMZ, and let's say if you had a phishing attempt on your organization. So let's say an attacker has gained Credentials for a user what would he do he would go and try these credentials on some external service right if you host a fake over page and you make the domain name look interesting enough he might try the Credentials he got from a phishing attempt on your over page and it's a great indication that you might have a compromise here

Next is passwords pretty or brute force you could I think this is again pretty much the same thing. So I think what I'm trying to say with all these techniques is Once we understand how an attacker is is Attackers methodology remains the same Once we understand that and defeat deploy decoys for those TTPs. We have a very good chance of detecting those and in this case if you deploy like multiple SMB decoys and if you see two or one more password attempts on your decoys it means there is a password spree on their network happening. On AWS, I mean we haven't done this so all the techniques which we talked about earlier can be done using the platform which I'll be showing but

this one we haven't implemented yet. But the way we could do it on AWS infrastructure is you could create fake EC2 instances deploy as three buckets and monitor them using CloudTrail. So if you have logs coming from your decoy assets on your AWS infrastructure, that's an indication.

So coming to deception strategy, we should be mindful about how we do our decoy placement. So we have generally two kinds of decoys. One is a client decoy, which could be an NBNS decoy for responder or for app poisoning, like an HTTP decoy. And we have server decoys, which are service decoys. So we've got to place them in the right VLANs. And we've got to have appropriate service on decoys. You can't have SSH and SMB running together.

We could also use decoys for threat intelligence. So all your decoys on your DMZ could be used for personalized threat intelligence. So you monitor all the events on your external decoys, which could be an indication of what are the source IPs which is trying to come after your infrastructure and stuff. Whitelist your scanning components. So if you have in-house scanning components, it's better to whitelist them so you don't see those alerts on your platform. And any password attempts on your decoys, you should probably give that a try that, or do they work on your production instances or not? So let's say if you have a password attempt on a decoy, and if the same password works on your production

environment, it's most likely that there is a compromise. So that's with the slides. I'll quickly pull up the tool. And

hopefully the demo gods are with us and the tool works well.

So this is the platform which we guys have developed. It's called Deja Vu. Initially, we had a command line version of it, but we thought having a web GUI would be much easier and easier to deploy and manage. So let me log into that.

Let me pull out the dashboard.

So if you see here, what we're doing here is we've deployed different kinds of decoys on various VLANs. And if an attacker interacts with any of your decoys, you would get an alert. And the challenge, I mean, the reason we've done this is the major challenge we saw in the deception space was scale how do you deploy hundred decoys right and how do you manage them let's say today as an administrator you've deployed ten decoys and you leave the company the next guy who comes in wouldn't even know there are decoys in an infrastructure so that that was what we're trying to solve here now coming to the platform so the first section is decoy management this is

what you can use to manage all your decoys your server decoys and your client decoys And what we tried to do here was keep things very simple. So we want to have a three-click approach. Within three clicks, you should be able to deploy a decoy. So that was our sort of philosophy in terms of UX we were trying to achieve. So you can create a decoy here and say, oh, I'll show you the VLAN spot. So what you would typically do is you'll have two interfaces. One is the management interface, and second is the decoy interface. So decoy interface would typically be a trunk interface where you will have multiple VLANs terminating. So you could add a VLAN from here

and then go to decoy management and deploy specific decoys on that VLAN. Once you've deployed the decoy, you could see all your decoys here.

And you would see all the raw logs here. So yeah, that's what we've tried to achieve with this and there are breadcrumbs.

Now with breadcrumbs, what you can do is now let's say you added a decoy, but you also want to add a domain entry to domain entry for main or DNS entry for the decoy. So you could do that using this generator. Script which you can turn on your DNS server to add this as a DNS entry a second one is honey hash This will generate a power shell script to inject honey hash But you can't detect if a honey hash has been used using this tool and the reason for that was we wanted to I mean our philosophy was to keep this completely independent um from your real environment. So we didn't want to install an agent on the domain controller to fetch

logs. So what we say here is generate honey hash from here and use your sim to monitor those logs for those accounts. And similarly, you can generate a PowerShell script for Kerberos tiny accounts.

Yeah, I guess. That's about it. You could download the tool from the GitHub link here. I think it's there on the presentation as well, so you could use that. And if you have any feedback with the tool, we would love to hear back on ways we can improve. So

yeah, thank you.

Any questions? So does the tool store the images for the decoys you want to deploy? They're going to deploy a Tomcat server. Does it store it in the tool, or do you have to save it in some repo where it goes to read? Right. Good question. So what we've done so far is we've taken common services, common images, like Tomcat, SSH, all of this, and we have Docker images for them on the platform. So you can use them as it is. If you want to add new images, you have to add it yourself. Yeah. So if you want to deploy like endpoint decoys, would you have to manually patch? Do you bother about patching the decoys to make

it look as close to production as possible? Or is it just decoy? So yes, there is an option to update the platform. Update the whole platform.

So what we do is, I mean, at least what we're trying to do is we will release constant updates to the platform, which will have the latest images of all the decoys we're trying to use.

Can you select a MAC address for the decoys? So when they're enumerating the network, you can make it more believable, like if it's a PLC or? Sure, I think, yeah, to answer your question, yes. And the way you would do that is when you're adding a decoy, you can now specify the MAC address and TTL value as well. So if you want to mimic Windows, you do 128.

I'm just curious, I mean, if I imagine rolling this out in an enterprise environment, I have a security team and I have, if you will, traditional administration team. And how, I mean, this seems like, from a security perspective, good, but from a, if I'm an administrator of file shares or whatever it is, that's going to be noise for me. I'm going to notice these weird things. I'm going to be trying to figure out who's running, you know, rogue, rogue file sharing and things like that. I'm gonna be triggering these alerts in the process. I'm wondering how you imagine that fits into a siloed organization. Sure, I think the idea of deception should be a very few guys should know

it. But like you said, admins would probably think that why is it there, right? You have to trust your admins. They should be knowing that there is deception in your environment. I don't see another way there.

Hey, sorry if this is a silly question. Two questions really. The first one is with regards to the MAC address, I'm assuming because it's being sent through the software, that seventh bit in the ethernet frame is gonna show that it's a spoofed MAC, correct?

We are setting the MAC address to the container. I mean, that would appear as a real MAC address. So it would show up as a burned-in MAC address as opposed to a spoofed one? Because that seventh bit right in the ethernet frame, it's going to be a zero or a one depending on whether it's burned in by the manufacturer or if it's set through software. Since we are spinning up a container here, we can specify our own MAC address is what I believe. So you wouldn't be able to make out whether it is spoofed or not. And then the second question, sorry, this might be another silly question. Is there a way, or do you

have, like, for a future release, are you thinking of doing ways, or coming up with a way to possibly start to map out expected traffic patterns or traffic flows within the network to the decoys, just a way to sort of detect anomalies sort of in real time, depending on flows? As of now, we have no plans to do any of those, yeah.

Is there a way to capture the payload itself that's being put onto the Docker containers? Good question. So I've seen a lot of commercial platforms doing that. So let's say you get you access an SSH decoy. They also show you what are the commands which an attacker has keyed in once he's got into the decoy, right? We don't do that. It is possible technically, but the reason we didn't want to do it is if you, if you see an alert on your decoy, you know that the attacker is there. We didn't want to go further from that. We just want to stop there. So yeah, it's possible technically we don't do it. And that was the reason. Yeah.

All right. Well, thank you very much for your talk.