Mosa and I do a lot of pentesting, red teaming, and we were kind of surprised by lack of deception technology.
We didn't encounter it too much, and when we did, it was mostly on the internal networks, nothing on the perimeter level, recon level.
And we both love Sacha Baron Cohen and his trolling, so we decided, let's start trolling.
So that's why the talk is called How Blue Penetrates You, a.k.a. Trolling Hackers.
So let's do it really quick. First of all, all of us are into the art of war, so all warfare is based on deception.
So a little bit about us, I'm Danny Golan, I'm the CTO of NetAlpha Financial Systems, and I'll let Mo introduce himself.
Mo Sanfried, I'm an advisor for Ledger Ops.
All right, so Mo, you take over now. You start with the slide.
Sure. So is everyone able to see my slides here?
Okay, so as Danny mentioned, you know, deception has been around for quite some time.
And, you know, the issue that we've had as of late with, you know, deception is that it's been heavily cited in favor of the red.
You know, you've got everything from phishing, cloned login pages, legitimate credential use, phishing, farming, smishing, HIDs, thumb drives.
It's been heavily lopsided in the deception game.
So, you know, as a red teamer and a pen tester who originally started out on the blue side, I always felt that it's been, you know, just completely skewed as far as, you know, how much in favor it's been on the red.
And, you know, personally to me, nothing's more frustrating as someone that's on the offensive side of security than running into, you know, red tape, bureaucracy, anything that, you know, results in wasted time.
And, you know, my personal experience with deception is that it may lead you to a few, you know, trails that are off the beaten path.
But over time, you start recognizing these patterns and it just isn't advanced and sophisticated enough where it's causing, you know, an adversary brutal pain.
What's brutal pain?
Well, you know, wasted time, burnt hours, you know, how am I going to, what's the best way to deter me?
Not really in terms of, you know, deterrence for me isn't detecting payloads or things like that.
Deterrence to me is just something that I spent, you know, let's say a week on to find out that it's not even a legitimate thing.
So my personal and our personal belief is to let's make deception even better.
Let's make deception so real so that, you know, it takes adversaries weeks, months, even if not longer to identify that, hey, you've just been pounding sand.
And so this is really what, you know, this is for the blue guys.
This is for, you know, the team that's in blue.
Currently, and, you know, referring to the ATT&CK model, you know, a lot of the deception is currently happening in, you know, a few portions of the model.
You know, we may see some deception inside of, you know, lateral movement.
We might see some deception in the discovery phase, but really not so much in the other aspects of the ATT&CK framework, the model.
So what we're suggesting is let's include, you know, what we're really trying to get at is like, let's get inception going in different phases.
Let's try to sprinkle in deception in as many places as possible to kind of, you know, make it even more complicated and difficult for adversaries to compromise systems.
So really, we just want to mislead people, mislead as much as possible.
So, you know, we're really kind of attacking the ATT&CK framework, you know, in order to make it better, in order to make deception better.
So, you know, as I mentioned, it's very limited.
You know, we need to go beyond reconnaissance and lateral movement.
And, you know, we want to take a multi-phase approach.
We want to have deception in as many phases as possible.
So, you know, we're talking about including at the recon phase, we want to have, you know, decoys for OSINT.
We want to insert fake employees into an organization.
And this is basically your organization's social media.
You know, we want to have basically decoys all over the place.
You know, we want to have decoys as far as password leaks.
Let's go and leak, you know, password dumps, you know, include false information and wait for that information to be used on our decoy, you know, DPNs, decoy OWA, decoy Citric Access, RDP, SharePoint.
Even when an attacker is enumerating your page, we want to have decoy subdomains.
And, you know, Daniel has a demo for that.
But what we really want to do is we just want to just make it so that people are getting completely frustrated targeting your organization.
That's the objective.
We want to, you know, hit them where it hurts.
And for, you know, if it's just a script kitty or if it's someone that doesn't have infinite resources, they'll go away after some time.
But if it's a targeted group, if it's an APT group, then, you know, they have all the time in the world.
So what can we do is we can burn their time.
We can make it very, very frustrating for them.
And that's the objective of, you know, our talk here.
So even, you know, some ideas that we've come up with is virtualized environments where, you know, adversaries are...
where we're intentionally running malicious payloads and providing them access into, you know, decoy environments so that that way we can kind of track and trace what they're doing.
We want to lure them in and provide new credentials to accounts that aren't even legitimate within Active Directory.
You know, really whatever we can to burn their time to, you know, eat up their resources.
All right.
So we came up with this little framework we call the triple D.
So we got on first, like, when you want to do deception, we don't want to do it to legitimate users.
So we want to detect when someone is tampering or trying to scan our site.
So we were looking at doing that.
You have a bunch of tools doing automated scans.
So we're able to fingerprint some of them.
We left some breadcrumbs in the front end code, like some development environment links and different credentials.
So if someone is using them, we can know that he's tampering with us.
If someone's doing active enumeration, whether it's a dare buster or doing subdomain enumeration, we can see the amount of requests is not reasonable.
So we can mark that.
And the last thing we did is we actually went into the application layer, into the code, and we implemented some small vulnerabilities that are pretty common.
But they changed the application flow.
I will demo this in a couple of minutes.
And then there's the deception part.
So we do, if we do detect someone trying to attack, we want to manipulate the application flow.
So it will look like everything is going well, like everything is working.
But in reality, he's going to a whole different environment with everything looks real, but he'll be just wasting a lot of time.
In terms of deception, there's also, we're doing some tests, adding like different headers using Nginx or proxy.
We're just putting headers for different frameworks and seeing how the tools react to that.
And for last, we did want to lure them in into a whole internal environment.
So we did put out a vulnerable service for that, which will also be demoed.
And in terms of deterrence, which is a third D, we wanted to force them to do as much manual work as we can.
And a lot of resources exhaustion, especially with hashed passwords, if they're trying to crack them, we just want to waste their time and resources.
And we saw that as deterrence.
So for manipulating subdomains, we took the top five tools for subdomain enumeration.
And we wanted to see how we can make them break or basically give a lot of noise so they don't really give the attackers value.
Because when we use them, you know, if you get 10, 20 domains, and they're legit, it's fine, you go over them.
But we want to give them as much noise as possible, like 100, 500, like 1000 subdomains.
So there's no way to actually automatically know which ones are real or not.
And it takes time.
So one of the ways that those tools actually detect subdomains is they look for SSL certificates.
So today with Let's Encrypt, it's free.
You can do up to 100 subdomains per certificate and up to 50 certificates per week.
So you can basically do 5000 subdomains.
It's a one-liner. It's pretty easy, as you can see.
And under the domains flag, you can put a bunch of domains.
This is all automated. It's free.
And then we wanted to do something for active enumeration as well.
So Nginx, which is like a really popular proxy, has a random index module, which lets you serve random pages.
So combine that with downloading 1000 pages from Wayback Machine.
And this block, which did not show up well, but as you can see, there's this HTTP block and the server block.
Ignore the part in the middle, which did not disappear. Sorry about that.
But under the location block, you can see that there's the random index.
And it will just, every time you go to any subdomain, it will serve you a random page.
And since Nginx works on top-down, so you put your legit server blocks above, so they will have your real servers.
Anything else will just go to random pages.
And it did break a couple of tools and even tools that do like spider-style scans.
It broke them as well because a bunch of random pages have a bunch of random links, and it just went haywire.
And in terms of DNS, you just put a CNAME record with a wildcard, and that worked really well for us.
So like we said, we love Sacha Baron Cohen, so this is a warning.
We did break a lot of tools, and I'll show you a demo right now.
So I'm using Amass to do enumeration.
So this video was about five minutes, and my computer was basically burning hot after those five minutes,
because the active enumeration just did not give so many results.
And the other two tools just legit froze.
We couldn't even keep going with them.
So you can see there's just a simple certificate with 100 domains.
Most of them are fake domains.
Let me just freeze that at the bottom at the end of this.
So I gave those domains names like Jenkins, like dev environment, staging environment, things that look legit.
So basically an attacker, this was only 100, but if I do 5,000, he would have to manually go and look at them.
So for the second thing, we're thinking like app level deception.
So the two solutions we've thought about were either going into the app's code and actually changing things.
So it's more work, it's custom for every web server you have, but it's very, very flexible.
You can basically implement any vulnerability you want.
And the other way was if you're using open source WAF, like Naxi or ModSecurity,
you can do it more generalized, especially for SQL injections and XSS.
But for this presentation, I'm just going to look at a simple code for a Flask web server.
So the vulnerability I chose, I've seen it a bit.
And it's a very bad vulnerability once you see it in the wild.
So I got a little Flask server, and I used JWT, Flask JWT,
which basically checks the JWT token, takes the identity out,
and it checks if it's a valid token or not, if it was tampered with based on the signature.
And there was an attack, which basically you put a non-null algorithm in the field,
and it bypasses the signature validation.
So what you can see here is I made a custom function that checks that identity.
But if it gets an exception for invalid signature or invalid algorithm,
it's not going to return an A user that will keep everything going regularly,
but we're going to manipulate the flow of the application.
So you can see that I did a print attacker detected,
and on the endpoint itself, you can see that I'm checking for the current user from that token.
If it's a valid user, it's a regular flow.
I use my ORM, which sanitizes the input and returns the user.
But under the else statement, you can see the tailored deceptive flow.
I have an on-purpose vulnerable line for SQL injection,
and I'm basically going to let him do a SQL injection
and return him just a bunch of bogus users with their hashed passwords.
And that's what he's going to get.
You can see the super simple SQL injection,
and I've minimized it so it doesn't show all the users,
but you can think of how long it'll take someone to actually put the time to crack those passwords
when they're actually... they don't mean anything.
So this was a super simple example.
You can generalize it to all of your Flask servers or any other framework by using decorators in Python.
So we made a couple people mad when we asked them to test the website,
because, you know, who likes wasting time?
And at some point, like, which news do you want?
You never know if it's real or not.
As long as you make it look 100% real, you know, people waste their time.
And we found that, especially with the subdomain enumeration,
we used to get a lot of scans on the demo site.
We put just a bunch of tools, and once we implemented some of these techniques,
it went down by around 70%.
So we're super happy to see that.
The second thing I want to show is, if you're familiar or not familiar with,
I'll do a quick intro to FUSE, which is file system and user space.
It's an interface to let you export a file system to the kernel,
and you get full control over reading, writing, listing.
And we took advantage of this to just sprinkle the file system
with a bunch of interesting files, like bb-backup, vm-backups,
like finance and accounting, Excel sheets.
And the nice thing is, it's all virtual, so you have full control
of how the file looks in terms of the size.
So we put, like, here you can see that the fake file name is bb-backup.eng
for encrypted. It's a 5-dig file.
And under the read function definition, you can see that it will,
if you try to read it, it will just generate random bytes.
It can do it, like, for days.
And this other thing we're experimenting with is adding random timeouts
when copying the files, because who... I mean, it's awful, you know,
you copy a 50-gig file, and then you get a timeout randomly.
So there we have Borad saying this file is real, not.
And first thing is, here I start the script called the DeceptiveFuse,
and I'm going to mount it to this folder called bb.
And now when I list the folder, we can see that this is a 4.7-gigabyte file.
And let's just try to read out the contents.
Yeah, so this will go on and go on and go on.
And since it's an uninterrupted file, it could be legit.
So now we're thinking, okay, we did the perimeter.
We did some app-level stuff.
We want to lure them in to our Declan environment.
So Vulnhub, for the win, great resource.
So these days with the cloud and DevOps, Dockers,
Vulnhub, the GitHub page is full of Docker images vulnerable
to specific vulnerabilities.
I chose Jenkins because who doesn't like popping a Jenkins server?
It's a goldmine for API keys, for source code.
Yeah, it's a goldmine for getting some info about the organization
and the code they're running.
So I deployed this on AWS, on ECS.
It's in a Docker image.
There's a link at the bottom of the slide.
This is a vulnerability found by OrangeSci,
which gives you a remote cloud execution.
And with the vulnerability added to the file,
I was able to add some users to the shadow file,
which will... let's see.
Okay, so... sorry about that.
So I'm going to start Netcat, just import 8080.
I'm going to use ngrok to give myself a publicly accessible address.
So this is the POC by OrangeSci.
Did a little bit of editing to make it work in Python 3.
It wasn't too bad.
This is the address.
You can see the address to the container running on AWS.
And I'm just going to post our curl command to read the shadow file
and send it over.
Yeah, and there we go.
You can see that we have LEG, Admiral, General, Aladin, Borat, Zagdaev, and Iran Marad
with pretty complex passwords.
The only one we left as an easy password was LEG,
because that's what we're going to use as credential reuse
to hop into the AD environment, which Mo will show in a minute.
So, yeah, let's go internal.
And I will post on GitHub the edited Docker file and all the code that I showed.
So, Mo?
Thank you, Danny.
That was really fun to watch.
So essentially, as Danny mentioned, we've got credential reuse.
So we intentionally have one user with a very easy password break
in our lab environment, pivoting from the external to internal.
Let's say in theory that this organization has a VPN accessible.
We're working with, let's say, a non-interactive login account.
We've got the user who has VPN access.
He hops into the internal.
He can't authenticate to any of the boxes because he has a non-interactive account.
Let's say he finds a box with null sessions.
He enumerates active directory.
What we're really doing is we're just basically replicating the flow
of what an adversary would do in the event that they have limited access,
just kind of like your typical post-exploitation flow.
So we set up a fake active directory environment,
and we didn't give the user the ability to access anything
with the actually login to a system.
So what we're doing is we're creating the environment.
We're creating a mock AD environment and putting out a low-hanging fruit
that does not actually come to fruit, if that makes sense.
So what we're doing is essentially we are leading people into...
we're luring them in with a whole bunch of low-hanging fruit,
but they're all going to be dead ends.
So yes, the attacker enumerates AD, but it's a mock AD.
The attributes are fake.
The users are non-existent.
They're basically in a sandbox, and they're just digging deeper and deeper
without even knowing that they're in a sandbox.
We have anonymous shares out there.
We lure them in with sensitive info.
We have the attacker upload malicious SCF files, have them fire up Responder
or different LMR NVT poisoning attacks.
We're going to respond to them.
We're effectively just throwing them into...
giving them breadcrumbs that ultimately lead to nowhere.
So we will have SMB boxes with SMB signing disabled.
They're going to have relay attempts.
We're going to give them net NTLM hashes with passwords that are incredible to crack,
just exceptionally difficult to crack.
Just have them burn up resources, burn up time, pound on sand, if you will.
So this includes exhausting different man-in-the-middle attacks.
What we really want to do is just have them run the gamut
before they really actually either, number one, give up,
or number two, are in it so deep that they typically get tunnel vision,
will have canaries out there.
Just kind of really want to, at the end of the day, just aggravate people.
If you have a really good product, you're going to aggravate people,
which is going to really just kind of...
the nature of a pen tester or someone that's on the offensive side
is typically you get tunnel vision.
You kind of start beating up on the same boxes, or you're repeating the same thing.
You kind of get into a routine.
So that's the kind of flow that we want to get people into.
Ultimately, we have telemetry in place.
We want to make it so that the attacker is going to get gradually louder and louder,
and the whole time we're just following their actions.
We're monitoring what they're doing.
So just a quick look at our user here, Ali G.
Respect.
And our mock environment here that we set up that we use for testing.
So a couple of tools, a couple of shout outs.
Number one, Deja Vu.
It's an open source deception framework that we used.
And Detection Lab, which the links will be available within the slides.
I highly recommend it for our internal environment.
We were able to spin something up within AWS and locally very, very quickly, very cost effective.
And on top of that, we leveraged Deception and Active Directory.
Nickel, he wrote Deploy Deception, an exceptional set of PowerShell scripts
that will allow you to create an entire mock Active Directory environment
with objects and attributes where you can create a fake user with different permissions
and really just kind of take out the tedious work that's involved in creating this sort of environment.
Obviously, you want to, you know, customize it as much as possible.
But, you know, a lot of respect for Nickel for putting this together.
You know, it allows the adversary to enumerate decoy objects with aggressive logging enabled
and just makes it exceptionally easy to set up.
And, you know, really sets up different types of attacks,
different types of, you know, users with passwords that don't expire,
people with members of elevated privilege groups, users with ACL rights.
Ultimately, what this allows is that it increases the time that an attacker is within your environment,
in your mock environment, and it increases a higher detection rate.
And it's, you know, as I mentioned, it's very easy to deploy with PowerShell.
So, you know, hopping on Ali G, we've got, you know, going into the lateral movement aspect,
we've got hunting creds, hunting tokens, hunting users.
Now, this is pretty typical of a lot of decoy products.
We're going to create a decoy admin account, and we have logging enabled for this account.
And we're going to deny login for this DA account.
So in the event that, you know, when the attacker does stumble upon our hunting creds or hunting tokens,
we'll get an alert for this account, someone attempting to log in.
And, you know, one of the methods that we leverage is by, you know, allowing, you know,
making sure that this dummy honey DA account doesn't have the ability to log on to any systems.
And we do this, one of the methods is by, you know, assigning that account to a computer that does not exist.
And this is the type of, you know, alert that you would get.
And, you know, that account is heavily logged and alerted.
And then a few things, you know, that in my research for this was going into different types of detection
that's in place for, you know, decoy environments.
And one of the projects that I stumbled upon is called the Honey Pot Buster,
which helps you, you know, kind of audit and test your environment, your decoy environment,
just to see what is the ability to actually detect, you know, your attackers within a decoy environment.
This kind of gives you an understanding of the legitimacy, how real does it, you know, does your decoy environment look.
So, some of the things that we could do to make your, to identify,
some of the things that we could do to identify whether your environment is a,
let's say, you know, you're in a decoy environment.
You could look at some of the products, and this is coming from Nicole's, and I apologize for mispronouncing your name,
but some of the things that he identified in his research was that, you know, the object SID,
the last login, the last logon timestamp, login count, bad password count.
This is from his research in identifying attributes within the mock Active Directory environment
that can basically, an attacker can look at and say, okay, you know, here's a user that's never logged on
and he has zero login attempts, zero failed password attempts.
You know, these are all attributes that can give away your decoy environment.
So, some of the things that you want to take into consideration when building your mock environment
to kind of make it look as real as possible.
Some of the other tools that, you know, that we've, that I've seen for detecting LMR and MBT poisoning,
there's, you know, honeypots that detect this sort of behavior.
It's fairly simple. A lot of them will, you know, broadcast to 255.255.255.255,
and this is a clear indication that you're looking at an LMR and MBT poisoning, you know, layer 2 honeypot.
And really simple bypass or workaround is to just set up TCP dump or Wireshark to look for that.
And, you know, ignore within, you know, whatever poisoning tool that you prefer.
And obviously, whenever you hop on a network, you want to use respond and analyze only mode.
So, you know, the final point, what we're getting at and kind of coming full circle
is that when building these types of environments, you want to keep it as realistic as possible.
You know, the objective is to, you know, make it so that the attacker, it takes an exceptionally long time
for the attacker to, you know, identify that they're in a staged environment, that it's false
and that they're kind of just being run around in circles.
And, you know, at the end of the day, this industry and this game, the nature of this game
is always going to be a game, cat and mouse. But if you can make it so that it takes the adversary
a really long time, hours and hours of their time has been wasted sitting around in this environment.
If you can burn their time, that is something that is finite and will ultimately never can,
no matter who you are, you can never buy more time.
So that's our objective and, you know...
Yeah, a lot of it was looking into how do we change this whole process from what Mo showed,
which is like the recon, the LinkedIn fake users and just like sprinkling passwords and fake password dumps
or like in real password dumps. But getting all that out there and those little click baits
for like going into those emails. And then from there, how we take it to the perimeter level
and the app level and just like pull them down into the rabbit hole until they get into that AV environment
and they've been just wasting weeks or like days, weeks, as long as they need for realizing that it was all nothing.
So, I mean, that's part of like the more sophisticated attackers, they will go in deeper and deeper
because they have the resources to actually crack all those passwords and do the manual labor.
But the deterrence is more for the strip kiddies or the lower level attackers that, you know,
once you hit them with 100 hashes and they actually need to start cracking it, they need to get those resources.
It deters a lot of attackers. And then especially for perimeter and app level, since you do not have really tools for that,
and it's mostly custom, so it's kind of easier to implement that into your flow without...
because there are no tools to detect. And I mean, this was just the start, you know, we had one presentation,
we were working on more cloud-related deception, utilizing the AWS agent and fake access keys,
which we hope that for next time we'll have something great with that. We will, but it'll just take us some time.
But yeah, this is an endless journey on going this path.
All right. Great talk, everyone. Really appreciate it. Our first question comes from Mark.
Are you looking at any disruptions in Office 365 or Azure AD?
Oh, you want to take that one? I'll just say that we did not look at Azure AD at all.
We did spin up an AD environment that's more similar to an internal network.
So most of the things we did on cloud was related to the web apps and the perimeter.
And then from there, it was like a pivot into an internal network.
Right. As Danny mentioned, this is just kind of the... Mark, thank you for the question.
And no, not yet, but we would love to work on that.
And, you know, if anyone's willing to... is interested in collaborating on this, Danny and I are beyond excited to do so.
And I guess one last question real quick for me.
I've seen a lot of companies and solutions, open source solutions, pop up in the active defense honeypots kind of arena.
Do both of you have any sort of predictions or where do you see the future of these tool sets going?
I'll say from my side that most tools that we saw and encountered in Pentest or Red Teaming,
like I said in the beginning, they were focused on internal networks.
And then today with this whole migration to the cloud and microservices and Docker containers,
which are replacing a lot of big web servers, these to be big like monolith web servers or Microsoft servers.
And we did not see any tools or anything relevant for that.
So we do hope that, you know, it will go to that path because like we saw in the second slide,
where we have the comparison of Deception and Red Team and Blue Team,
like Blue Teaming is way, way behind on Deception technologies.
And then, I mean, we did this talk because we are trying to push this forward in this research.
So hopefully, it'll advance a lot.