This webcast was originally published on August 1st, 2019.
In this video, David Fletcher discusses the importance of early detection of attackers in your environment by leveraging characteristics of attacks and strategically placing resources in Active Directory. The presentation delves into various tactics including password spraying and the use of tactical deception with planted artifacts to set off tripwires. The focus is on reducing the time to identify breaches by catching attackers early in their methodology, using a combination of proactive security measures and strategic environmental setups.
- Tactical deception using active directory to detect attacks early is a core strategy discussed.
- Importance of creating strong, believable user accounts for setting traps for attackers.
- The use of specific tools and scripts like CRED defense Toolkit and Powershell to enhance security measures.
Highlights
Full Video
Transcript
David Fletcher
Awesome. So today I just wanted to talk to everybody about really, increasing the chances of attacking attackers early on when they’re in your environment by taking advantage of, some of the characteristics of those attacks and planting resources in active directory.
just a little bit about me, I’m a tester at Black Hills. I’ve got, I hold the sans sti msi se degree.
I have lots of gxers, hardware enthusiasts, I’ve built or been involved in a lot of the labs at wild west hackfest, and I do love hunting and fishing.
So in I actually put this talk together for a bunch of different school districts. And in researching for the talk, I took a look at the 2019 Verizon dbir, and some of the things that are in, DBIr are a little bit telling.
Obviously, the era of external exploitation continues to decrease. So we see about a third of, all breaches have social engineering involved.
And that’s up, from 17% in 2013. And then 30% of breaches involved stolen credentials. And when we talk about stolen credentials in DBIR, they explicitly called out web based email.
So, most of those are web based attacks against email portals, whether hosted on site with exchange, OA, or in the cloud with resources like Office 365 or Gmail.
And realize that MFA doesn’t eliminate the risk of stolen credentials, it just reduces it. Obviously we can use tools like cred sniper or evil nginx to clone the login page, phish your users, and then get credentials that way.
And even if you have MFA enabled, once we have those cookies for the authenticated site, we tend to get access to the internal network or the ability to get access to the internal network through that email portal.
The last thing that was kind of telling in the report is that 56% of breaches still took more than a month to discover after initial compromise. And what I’d like to focus on is those last two bullets.
Really. One of the attacks that we’re going to talk about is, password spraying, and we’re going to look at a way to try to detect that password spraying attack early, using nothing more than accounts in active directory.
but the idea is overall, we want to reduce the amount of time it takes to identify a breach by hopefully catching the attacker early in their methodology, by taking advantage of things that they’re going to be looking for.
so first and foremost, how do we do this? We’re going to be using tactical deception. So we’re going to plant artifacts in the environment, and those artifacts are going to be specifically put there to try to entice them to set up off one of our tripwires.
And the way that we’re going to do that is we’re going to target common attacks that we use early on in our in our methodology, because those common attacks often involve low hanging fruit.
So there’s a high risk of reward, or there’s a high reward for the attacker and a low risk of getting caught within the environment. So by taking advantage of these particular attacks, we can create an early warning system in our environment, and it also gives the benefit of proactively checking our own environments for the preconditions, for these specific attacks.
And I know that we’ve talked about a lot of these attacks over and over on various webcasts and in blog posts, but the reason we talk about them all the time is because they work in the vast majority of cases.
So the techniques that I’m going to talk about are things that I use on just about every test. Obviously you want to check your own environment first, make sure you remediate those conditions so that when an attacker gets an opportunity, they’re not able to exploit that opportunity.
Because largely what we’re doing here is creating up infrastructure to alert on malicious behavior within the environment and give you context, relevant information, but it’s not going to stop the attacker from having successfully.
So you’ll be able to identify the root machine where things are occurring from the type of attack that’s going on. But we’re not actually stopping the attacker from abusing whatever condition might exist in the environment.
In addition, you might want to think about putting other protections in place. So for instance, things that I would recommend first and foremost lapse local administrator password solution, from Microsoft.
It randomizes the local administrator password on each one of your machines so that if the attacker can compromise those credentials on a given machine, it stems the spread across the environment.
And you want to make sure that laps is working correctly within your environment because often what we’ll find is we’ll have an environment that’s implemented laps and it’s only partially working.
Another one is credential guard. With credential guard, older operating systems have w digest enabled so that I can get plaintext credentials from memory.
And then, I’m sorry, I’m looking at the questions I just got thrown off. but credential guard will limit the amount of information that’s out there. Even on modern windows operating systems.
I can still get hashes from memory. so credentials guard just makes it harder to get at that information. In addition, Windows defender does a really great job at catching a lot of the stuff that we’re going to be, talking about, especially with malicious powershell.
but realize, even though I’m talking about these individual powershell scripts, most of this functionality has been ported to different platforms and different languages.
so that what you really need to focus on is that underlying abuse. So I don’t want to just identify powershell activity in my environment.
I want to look at the preconditions and identify activity based on those conditions, if that makes sense. So the first thing that we’re really interested in is creating resources in active directory for the deceptions that we’re going to set up for each one of those attacks.
By and large, what we’re talking about is creating user accounts. And some of the user accounts are going to involve planted credentials in the environment. Other user accounts are just going to exist so that we can see specific attacks happening within the environment.
So some things that I would consider for planted credentials and plannered user accounts create a single account for each individual ruse or attack that you’re trying to identify.
When you create those accounts, make sure that they have very strong actual passwords. If you feel like you need to keep those passwords, storm and a password vault, really, unless you’re looking to blend in with the rest of the user accounts in your environment, you don’t really need to keep these passwords.
if you set password never expires on the account, it’s very unlikely that I’m going to look for that attribute and I’m still going to interact with those accounts.
In addition, you want to have believable planning credentials. So maybe use common weak password generation techniques.
So season and year, month and year, maybe the name of the service within Leet speak, some variation on your company name, but you want it to be something that the attacker, is going to believe is a valid password, then you want to have believable attributes.
So a lot of times when I see honey resources in an environment, I don’t ever, ever interact with them because they don’t have believable attributes.
If the account’s disabled, I’m not going to mess with it. If user account control is set to something weird, I’m not going to mess with it. If I look at the account and I see weird group membership, like I’m only a member of domain users, that’s not really useful for me as an attacker to escalate privilege or increase my access to the environment.
So the chances that I’m going to use it are much smaller. So with those user accounts you want to also make sure they’re in what looks like legitimate groups.
There’s two strategies that you can really use here. I can use the legitimate use groups in my environment or I can see dummy groups. If I’m using legitimate groups and my accounts have strong passwords and I’m auditing authentication success and failure for each one of those accounts, do I really need to worry about those accounts being in legitimate groups outside of management of those, of that infrastructure?
I probably don’t. So in most cases what I’d recommend is using legitimate groups because you get all of that infrastructure that comes with it, you get the other group members, you get access to real resources, and if anybody ever tries to use the account then you’re going to get an alert.
So if you try to use dummy groups, make sure that you’re using the same naming convention as your legitimate groups. Target the groups to the purpose of the user account.
so specifically you make them a member of a specific department, make the groups look legitimate for that department, and then just don’t assign any resources to the groups.
So based on Microsoft guidelines, when you’re creating group structures in active directory, you’re assigning users to global groups, global groups to local groups, local groups to resources.
If I never assign a group to a resource, does that group or user account ever get any access to anything useful? Normally not at all.
If I’m worried about what access I’m granting to a user, maybe I want to create a group policy object that denies access to those resources. But that’s really taking it to the extreme and I don’t think it’s horribly useful or necessary in the situations that I’m going to talk about.
Any questions?
Jason Blanchard
Dave?
David Fletcher
I’m trying to keep track of them. I see easiest way to explain to management that the honey users are not increasing risk. yeah, well I see login not enabled, but that’s kind of a tough one because as an attacker, if I get in the environment once, the first thing I’m going to do once I find credentials is see what groups that user account has access to and whether the account is enabled in active directory.
that throws it away for me. What I would usually do is say I’ve got really strong passwords on these accounts and I’m instrumenting all access.
You can test that and demonstrate them to them that you can see any use with the account whatsoever. And really what you want to focus on is these accounts have zero legitimate use within the environment and I’m not expecting anyone to interact with them.
Every interaction action becomes suspicious. yeah, and then this one about.
Jason Blanchard
Can, credential guard GPo be enabled when it’s not in the BIOS options?
David Fletcher
that I’m not sure of. we rarely go to the extent of, enabling credential guard within an environment.
Usually it’s our customers who’s actually implementing credential guard. What we see is once credential guard is enabled, and you have other lsas protections, it becomes very difficult to get any traction on an endpoint because you end up looking in lsas, for creds, you don’t see creds, you don’t see hashes.
so it becomes really hard to use that information that’s out there. So there are now tools out there like honey pot buster that will automate the detection of honey accounts.
Do you have any tips to fool these types of tools? It really depends on the techniques that they’re using to identify the honey accounts. If your accounts look 100% legitimate and you’re doing things like, setting up your attributes, the same group membership, the same, it’s going to be very hard for them to identify the actual honey accounts from the legitimate accounts.
And it really depends on what specifically they’re talking about. From a honey account perspective. If it’s user accounts, that’s going to be pretty hard.
because from my perspective, when I look at user accounts, I think of things like service accounts and I’ve cracked passwords for service accounts that haven’t been changed since 1994.
So throwing away accounts because of aging or different, variations of attributes in active directory seems, kind of dangerous to me.
But when you’re talking about computer accounts, yeah, there are a lot of reasons that I’m not going to interact with something. and maybe I go to the point of fingerprinting those specific computer, accounts based, on services that are exposed, based on attributes that should be populated in active directory.
I would say that that would be a depends, and that’s kind of why I’m talking about computer accounts here is because I don’t need to. For this particular set of attacks, I wouldn’t recommend creating a single computer account, because it’s completely unnecessary.
But what I’ve seen is in organizations where I’m testing that have honey pots, they create computer accounts. And then at the end of the engagement they say, hey, we’ve got these honey pots out there and we noticed that you didn’t interact with any of them.
Well, when I get into an active directory environment, one of the first things that I’m going to do is look at the attributes in active directory. I’m going to look at info, description, comment, operating system.
If those aren’t populated like other accounts in active directory, then my propensity to interact with them starts to drop significantly.
In addition, if you look at password lastset and last logon timestamp, and you understand how active directory works, then that these fields get updated semi frequently.
So with password last set based on Microsoft’s documentation, every 30 days the computer account’s going to change its password. In active directory, that attribute gets replicated throughout active directory, so I can see it pretty much everywhere.
If I see something that’s more than a month or two old, I’m not going to interact with that host, no matter how enticing it looks to me. same thing with last logon timestamp, it gets updated pretty frequently.
The only difference is this one doesn’t get replicated. So I tend to trust last logon timestamp a lot less than I do password lastset. but if you don’t have an operating system attribute and password lastset, those are obvious red flags to me, so I won’t touch those machines at all.
The problem with password last set and last log on timestamp is they’re not horribly easy to update in an automated fashion if you’re not using a Windows operating system.
So bottom line for all of this is that creativity is king. Obviously your environment better than anyone else, so the first thing you should do is identify the critical resources in your environment, the critical information, wherever those crown jewels are, build accounts with those resources in mind.
So think about your group membership, what ous organ or your user accounts are in. Identify, how you would expect an attacker to get to those resources, what locations they would have to come through, and then overall try to make it manageable.
So maybe I create a new, department in my organization. I create all my honey resources in that department, create a group structure for that, create organizational units, and then I create a whole ecosystem of deception.
And as we talk about individual attacks, if an attack surfaces that is based on active directory, it’s likely that you’re going to be able to use these types of resources and extend the functionality so that you can identify different attacks as they appear.
So I’ve got a new question. do if dumping lsas using direct system calls can bypass credential guard example? I think I’ve got a blog post that one.
I’m not sure. I, know that we’ve used internal, monologue, to perform SMB handshakes in memory, and it has worked well.
we bypassed edr, using internal, monologue to get hashes, but they’re not straight, ntlm hashes.
They’re [email protected], ntlm v one. So the next thing I’m going to talk about is tools. And really we’re talking about one tool. In this case, the slide deck has one additional attack in it, but I had to strip it out for, for time’s sake.
I think if Jason is going to post the slides, it’s going to be in there. the tool that I would recommend specifically because we’re going to talk about multicast DNS poisoning is responder guard.
and I recently rewrote responder guard and we’re going to talk about that, when we talk about multicast DNS. but other capabilities you should consider in cred defense toolkit are password auditing and password filtering implementation.
So if you have even a strong password policy, but you allow users to create crappy passwords, that’s a problem. So at the very least, having the password filter functionality, of credefense toolkit is a plus because I can keep people from using season and year, month and year variations, on my company name.
And I can also use it to audit my passwords to identify when password reuse is in effect or when people are using those horrible passwords in my environment.
Jason Blanchard
Hey, Dave?
David Fletcher
Yes.
Jason Blanchard
How much does the longer passwords reduce the crappy password problem, in your view? So when we get to like, we use 16 and 24?
David Fletcher
Yeah, I think once you get to 16 and 24, things get much more difficult. but I think the atomicity of the password is going to change as we get longer and longer.
right now, the atom in a password is a character. Maybe it becomes a word at some point. I know that Kent has been working on using, project Gutenberg to crack passwords using word combinations, from commonly published novels.
so I think at some point we’re going to go that way as we abandon complexity and we may have to revisit it in the future.
Jason Blanchard
Sure.
David Fletcher
But I think the real issue is guessable passwords. once an attacker is on the inside of the network, so we want to try to eliminate those.
So in addition to the, the default functionality that’s offered by cred defense toolkit, I’ve been working on a honey resource generation script.
So essentially it’s an XML file that you can use to generate all of these accounts for each individual attack purpose. And you just feed it to a powershell script.
It creates all the resources for you, outputs, anything that you need to plant in your environment, with variation in those resources so that they’re not easily identified.
but it also will work with cred defense event parser so I can set up event forwarding so that I’m getting all of the authentication success and failure messages and all of the events that are associated with Kerberos thing and the custom events that I’m going to talk about.
And then cred defense event parser will generate contexts, relevant alerts for each one of the attacks so that you can see it.
So the last thing on the slide is event forwarding. There’s a blog post by Derek Banks about setting up event forwarding if you don’t have a Sim, and I would definitely recommend taking a look at it.
it’ll get you at least the ability to detect all of the attacks that we’re going to talk about here. So next we’re going to get into the attacks and the general flow for each one of the attacks is I’m going to talk about the attack, and its salient characteristics.
Then I’m going to discuss the attack itself and discuss what we’re going to use as deception strategy. So the first attack we’re going to talk about is reconnaissance.
And once I get into a Windows active directory environment I spend a lot of time looking around to kind of get my bearings. and I’m going to look for a bunch of different things.
If anybody’s familiar with powerup, and get GPP password and power view. These are all Powershell automated scripts to identify weaknesses in the environment that are essentially low hanging fruit, in the form of in most cases credentials.
So I’ll look for unattended installation files in c Windows Panther. If those have credentials, I may use those credentials. I’ll check out the sysvol share and I am going to look for GPP.
Even though it has been kind of defunct since 2014, we do find it on occasion and it’s always useful when we find it.
I’m also going to look at your logon scripts, so I’ll download all of your scripts. [email protected] use statement, check and see if there’s any credential usage in there, identify any binaries that you planted out there, maybe run strings on them, identify credentials in those, and potentially use those as well.
I’m a huge fan of active directory explorer. so it allows me to view the active directory schema in the same way that active directory users and computers presents it to an administrator.
And I’ll look at those attributes and see if I can find credentials there. And then finally I’ll look in file shares. So the first deception that we’re going to talk about is unattended installation files.
Normally what I see when I look at an unintended installation file in a modern Windows environment is the bottom graphic where the password has asterisk sensitive data deleted.
There’s no reason that that has to be like this. As a defender, one of the things that I might want to do is take this unattended installation file, plant credentials in it, use a user account specific to this purpose with strong password, believable attributes, believable group membership, and then drop it on every m machine in my environment.
Now when an attacker checks my unattended installation file, finds my credentials and tries to use them on the backend, I’m instrumenting all of my authentication success and failure messages and looking specifically for this user account.
When I see this user account being used, I can pop an alert that says hey, somebody is using credentials from the UIF that we publish to all of our machines, in the active directory environment.
The next thing I’m going to do is look at the sysvolshare. Like I said, I’m going to grab all your logon scripts, I’m going to [email protected] use statement in there. And really I’m not, I’m not spending any time doing this because I’m going to grab the whole folder, I’m going to exfiltrate it, I’m going to use grep, and then I’m going to look at anything that’s in there that might have credentials in it instead of just leaving that for an attacker to find.
or as a deception strategy, maybe what I can do is grab one of my Logon scripts, create a backup copy of it. Nobody actually uses it, and I have a net use statement in my Logon script that has a username and password for a legitimate user in my active directory environment.
In reality that user has a strong password, believable group membership, believable attributes but the password that I planted is complete.
It’s complete bunk for the attacker. So when they go to use it, I’m monitoring authentication success and failure messages. And when I see this user account that is specific for this purpose, I can pop an alert that says, hey, I’ve got credential usage from sysvol in, one of my logon scripts.
I need to go take a look at the source account or the source machine that’s performing this activity.
Next one is group policy preferences. round about 2012, Microsoft realized that the encryption key that was used to encrypt the passwords included in group policy preference files for, provisioning local user accounts, creating tasks, on machines.
They figured out that it was disclosed. Now it’s a static key. Anybody who knows the key can decrypt the cpassword field in the XML file that is used for group policy preferences.
Microsoft patched that in 2014, but when they patched it, they didn’t just eliminate, it altogether. What they did is they said, okay, from now on you can’t create new group policy preferences.
However, any group policy preference file that exists that has credentials in it remains in the environment. We still see GPP files with credentials today.
So instead of just completely eliminating them, from our environment as a deceptive strategy, what we do is we create another account. This account has a strong password, believable attributes, believable group membership, and then we plant a crappy password in our cpassword file, or in our cpassword attribute in our group policy preference file.
When, GetGPP password parses the XML file, all of the attributes that it shows to you are in the file itself. So when you see the changed attribute and the actual cpassword that’s displayed, that’s read from the file.
So I can create a new GuId based folder, I can create a new, what appears to be legitimate group policy folder structure and drop my GPP file in there so that when a tool like Getgpp password is run, it shows the credentials to the user.
They check active directory, make sure that everything looks semi legit, and then when they use the credentials, we get our context relevant alert credential usage from GPP.
Next one is active directory. We see active directory or credentials in the active directory schema, quite a bit, and there’s usually two reasons for it.
The first reason is that I’ve installed some legacy tool or some third party application, and that tool or application has altered the masking on one of the attributes of an affected account.
So in the last screenshot, at the bottom what you see is our backup user and our SQL service account. And what’s actually displayed is the user password field.
In the user password field you have ASCII encoded decimal that represents the actual password for that user account. So what I can do is take each one of those numbers, turn it into its ASCII equivalent, and I get the actual password.
Oftentimes when we find these, the user is either high privileged, in the context of the entire domain, or they have administrative privileges on the target server where that service is running.
So that’s extremely dangerous. So I want to make sure that when I’m auditing my environment I check for those sorts of things. In addition, the other thing that we see is administrators have this notion that if a user doesn’t have access to active directory users and computers, then they can’t read the attributes in active directory, which is completely false.
So a lot of times when I get into an environment I’ll use ad explorer, I’ll use powerview, or I’ve got various other tools that I’ve put together that will read attributes that I’m interested in out of active directory and then present them to me so that I can peruse them.
And often what we’ll find is in the comment, the info, or the description field. The administrator has put passwords for various accounts and often the accounts that have passwords in them are service accounts or shared mailboxes that we can use to further compromise the environment.
So first and foremost we want to eliminate those. But then what we might do is create oh, our own accounts specific to this purpose that do the exact same thing that we’ve talked about with the other reconnaissance steps.
So I create an account for the specific to this purpose and then I plant credentials in attributes that are exposed where an attacker might read them. What I would recommend is using comment info or description because they’re easy to update.
The other from a defensive standpoint, I would recommend that you check comment info description for those mistakes and then check user password, Unix user password, Unicode password, MsSFU 30 password if it exists, and MS MCs ADM M pwd.
That last one is where the laps password is stored. And we found environments where unwittingly the, laps password is actually exposed because someone changed the NTFS permissions on the attribute itself.
The last place that I would think, about from a defensive standpoint where I would plant, credentials for reconnaissance is file shares, and you can get very complex with this, but what I would start with is the common map network drives.
As tools have become more mature and they see at large enumeration, I’ve tended to pull back from that.
And what I’ll do is I’ll grab the map network drive policy and then I’ll grab the logon scripts from the sysvol share and I’ll look at where map network drives are being used within the environment.
And I’ll start with the common ones because users can write information there obviously. And then I’ll plant as a defender, I think about planting credentials in say the root of the share.
In the root of the share. I probably don’t want to plant something obvious like a passwords text, but what I might do is create a binary that has a username and password embedded in it.
Compile that and drop it in the root of the share, so that if an attacker sees that binary there, they may be apt to pull it off and decompile it and discover the credentials.
Another one that I really like is accessible home directories. So what I would do there is for one of my honey user accounts and I would create a user account specific to this purpose.
When I create their home directory, I would add domain users with read privileges to the home directory.
Then I would plant the proverbial passwords txt file in that home directory with some other legitimate looking content.
Then when the attacker attempts to enumerate home directories, which often what I’ll do is I’ll look at active directory, I’ll look at the home directory attribute, identify where those shares are being hosted, and then I’ll try to mount the root of the share.
If I can get to the root of that share, I’ll do a search for index dat or thumbs db. If I see any entries, I know that those shares are accessible to me, and then I’ll poke around in them.
And often we’ll find passwords docx or passwords txt. So if you plant a file in that directory structure, it’s likely that an attacker is going to find it at some point.
Try to use those credentials and tip you off. The last one that I would look at is it related folders. And essentially what I would recommend is I almost universally look for things like web config files that have credentials in them.
So I would grab a project on GitHub that has technology, that I’m using, plant legitimate credentials in the web config file, create an account specific to that purpose with strong password, believable username or believable group membership, believable attributes and then monitor for any usage of that account.
On top of that, you should consider domain enumeration if you don’t have tools in place to identify it. So a lot of organizations that we test have the ability to threshold alert.
So if I connect to say ten resources that I’ve never connected to prior to or maybe within the last 30 days, then I generate an alert and say hey, this is suspicious behavior, somebody might have hijacked this account.
If you don’t have those sort of protections in place, then you want to make sure that you consider those. So plant enticing computer accounts.
Those computer accounts should have vulnerable operating systems in the operating system attribute and then try to entice the attacker to interact with those.
Jason Blanchard
Hey Dave.
David Fletcher
Yep.
Jason Blanchard
We got a question here. Pretty good one, I think with move to the cloud and particularly o 365 azure ad, many orgs synced to azure Ad identity is then in two places.
I wonder what the parallel recommendations are for azure Ad honeycounts and credential protection, especially not synced built in administration roles and their members.
David Fletcher
That’s a great question. I know that Mike Felch is doing a lot of research with Azure, but if you’re instrumenting authentication, success and failure both locally, in your on prem active directory and doing the same in Azure, a lot of these detections are probably going to a lot of these are going to probably be useful, in both environments.
So the next attack that we’re going to talk about is password spraying. And we talked about so for those that aren’t aware, in password spraying, mechanically what I’m going to do is try to enumerate the password policy if I can, or at least make a best guess because what I want to do is avoid account lockout and try to avoid tipping my hand, to the organization that I’m attacking.
Then I’m going to generate a list of user accounts. Internally this is very easy because I can do it from active directory itself. Externally I can use tools like LinkedIn to gather employee first names and last names and then generate users names based on those first names and last names.
Once I have what I believe are useful usernames, I’m going to guess one password for the entire population. And the chances that somebody’s going to have the password that I’m guessing, tend to get pretty high if you don’t have a strong password policy set for your organization.
One thing to realize is that we can use multiple interfaces for doing password springs. So I can use SMB, I can use exchange both locally on the local network and through interfaces like Outlook web access or Office 365 or ad fs.
Or I can use lync and I can even. So, if you enumerate all of the web interfaces that are exposed to the Internet and you find one that challenges for NTLM authentication, it’s likely that you’re going to be able to do passwords or perform password spraying against that interface as well.
So I want to minimize those as much as possible. And anything that’s exposed to the Internet I want two factor authentication on. So in order to identify password spraying, what we can do is create an additional set of honey user accounts.
But in this case maybe I want to create a bunch of dummy user accounts, same criteria as before, strong passwords, a believable group membership, believable attributes so that they don’t get omitted from the password spray.
If I’m worried about external password spraying or at least identifying it, I can seed LinkedIn profiles with all of these usernames and password or these fake usernames so that the attacker has a pretty good chance of generating a username based on one of my fake user accounts or fake profiles.
And then I set strong passwords on all of the accounts and I monitor for any kind of logon attempt. So if I see a authentication failure message on any one of these accounts, I can generate a context relevant alert that says hey, you’ve got a password spray in progress.
Now the one issue with password spraying is that I’m trying to password spray the entire environment. So any of the other accounts that we generated are going to get a log on as well.
So when I’m getting alerts for password spraying, I’m also going to get alerts for pretty much everything else, that I’ve planted in the environment.
So there’s a question about how many accounts we typically password spray against, at once. It really depends on the environment.
if we see that you’ve got strong password or strong protections internally, we may throttle our password spraying so that we only make one guess every, 30 seconds or so.
But what we’re going to do is try to spray the entire environment, because the chances that somebody’s going to use one of those weak passwords are going to go up, the more users we’re actually spreading against.
Notice in the top graphic I just use the phonetic Alphabet, to create all of my users. Obviously this is going to be an indicator, but it gives you an idea that maybe I want to create 26 user accounts, monitor them all.
Then whenever I see any one of those user accounts appear in 4625 event, I throw my alert saying hey, somebody’s password spraying us and I can identify the source machine that those authentication requests are coming from and then isolate it from the network and go into full ir mode.
Next, we have kerberoasting. so in kerberoasting I take advantage of services that I want to locate. using Kerberos have service principal names published in active directory.
So what I do is I query the domain controller for those service principal names and then for every user account that has a service principal name I request a TGS ticket.
The TGS ticket has enough information in it to recover the plaintext password for the account using password cracking. So in this case, unless you’ve got really good protections in place, there’s a very low risk of detection and a very high reward because most of these accounts are going to be service account related.
So I’ve got elevated privileges either on the target machine or in active directory itself. And this detection here is straight out of credit toolkit.
So instead of just generating a honey user account and hoping somebody tries to use it, I generate my honey user account. I create an SPN and associate it with that account using set SPN.
Then on the domain controller I can monitor for event id 4769. Anytime that event id pops up with one of my honey user accounts I can generate a context relevant alert that says hey, somebody’s trying to kerberoast in our environment.
The bad thing about this is if your service accounts don’t have strong passwords, the attacker has already got the hashes for them. So you have to be prepared for this.
a lot of the customers that I talk to talk about their service accounts and say hey, it’s really hard to force people to change these service accounts because they’re afraid that specific services are going to break as a result of the password change.
And my response is universally, I’d rather change that password under controlled conditions and make sure and identify how it’s broken, make sure that it gets documented, and avoided in the future.
Then have a compromise and have to do it on the fly because either way you’re going to see downtime and there’s going to be a problem, and it’s unlikely that you’re going to be able to document it when you’re in the midst of an emergency.
Next we have multicast DNS poisoning. And in Windows default configuration, what happens is when primary DNS fails standard DNS, I automatically default to Llmnr.
So link local multicast name resolution or NBNS netbios name service to do name resolution on my local subnet.
So when primary DNS fails, what happens is my machine shouts out on my subnet and says, hey, does anybody know the IP address for this hostname that I can’t resolve using traditional DNS?
Anybody who responds wins. That service, resolves the name using that IP address, and then the poison machine connects to whatever services on the other end.
Typically we exploit this using invaoresponder. Once I’ve got a spoofer running, I also set up services running in the background and I can do things like credential harvest or SMB relay.
If SMB signing is disabled with an SMB relay, what I do is I lie to another machine on the network when it tries to connect to me.
I challenge for authentication. then I relay that authentication to a third party where that user is suspected to have elevated privileges.
Now I can execute commands on that third party system without ever having known credentials for the account that I’ve just compromised.
So in the cred defense toolkit, bobolic created responderguard. And what responderguard does is it’s a scanner and it sends unicast NBNs requests out to every host on the domain or within the network that you’ve specified, and it listens for responses.
If it gets a response, then what I, there’s no legitimate purpose for that response. I should never get a response.
So what I do is I log an alert as event id 8415, and I send honey creds to that waiting service.
Now, when that service gets the honeycreds, the you, the attacker can either try to crack them or try to use them in relaying. And I can generate context relevant alerts for this purpose as well.
Again, I’m creating a specific user account for this specific purpose. It has a strong password, believable attributes, believable group membership, so that I have the greatest chance of fooling the attacker.
Now, I get potentially two different alerts, based on the attack itself. First, I get an alert on the actual poisoning activity.
This tells me where the poisoner is, and I can isolate that host from the network. Next, if the attacker actually tries to crack those credentials and reveals the plaintext password, I’ll get a secondary alert when the attacker tries to use them.
So if the attacker has already pivoted on the network, I might get a secondary alert that says, hey, the attacker is over here. Now one problem with that, with this whole scheme is that unicast NBNS requests are unusual.
Normally when I’m doing NBNS resolution, I’m sending a broadcast out to my subnet and hoping that one of the machines in my subnet can respond for me.
So Inveigh has created an evaderg, so evade responder guard option that looks specifically for those unicast IP addresses in the source field or I’m sorry, in the destination field.
If it sees an NBNs request that isn’t a broadcast, then it just completely ignores it. What I did is over the last couple of weeks I’ve rewritten responderguard to include responderguard agent.
And what responderguard agent does is it sends legitimate broadcast and multicast requests. And you can specify any combination of NBNs, llmnr or MDNs.
It works exactly like responder guard. So if I send out my requests on the subnet, if I get any kind of response, then I’m going to generate alert.
I’m going to send honey creds if I’m configured to do so. And then use of those honey creds would also generate an alert. And because it’s a powershell script, I can deploy it by GPO so I can set up my GPO so it’s targeting individual machines on different subnets and then get it running and set up event forwarding so that I get those events that are generated by responderguard itself.
There is another slide at the beginning in the tools section that talks about Powershell honey port. it’s, it’s a script that works.
It’s a Powershell script that you can use to create a listening honey port on a windows machine. On any arbitrary port. you can give it a whitelist.
That whitelist will identify legitimate machines that are going to connect to it. So for instance, maybe I want to whitelist my vulnerability scanner and then whenever it gets any interaction whatsoever, it’ll generate an alert on the machine that you can forward and then instrument on the backend to look for malicious activity.
one of the other scripts that I was thinking about when I was putting this presentation together was Powerup SQL by default. When you run Powerapp SQL, one of the primary uses for it is going to be enumeration of active directory, just like all of the Kerberos thing tools focus on those service principal names.
One of the primary uses for Powerup SQL is to search active directory using service principal name, then check accessibility of that target SQL server.
And then once I know that a SQL server is accessible to me I can evaluate for career configuration errors. So I can see if XP command shell is enabled.
I can see if I’m running as DBA and I can enable those tools that might make it easier for me to compromise the underlying host or exfill information from the SQL database.
So in this case what I want to do is I want to create another honey account, believable attributes, strong password, believable group membership and then assign an SPN to my honey account.
With my SPN I want to make sure that it has the MSSQL SVC prefix on it. When when Powerup SQL enumerates the SQL servers from active directory it’s looking for this prefix.
Now I grab any Windows host and I run my Powershell honey port on that Windows host on port 1433 or whatever port I’ve specified in the service principal name.
And when I run get SQL connection test threaded using Powerup SQL it’s going to connect to that machine and generate an alert for me. Now I get an alert saying hey somebody has probed my honey port that isn’t in the whitelist and it’s probably SQL server enumeration inside of my target environment.
So that was the last attack that I wanted to talk about and really I’m hoping that if you decide to implement these deceptions they’re going to reduce the mean time to detection within your environment.
Obviously all of this stuff that we’ve talked about is zero cost. Really when you think about it, all we’ve created is a bunch of user accounts with really good passwords.
Assign them to groups and then we don’t ever touch those usernames. In the future we hope that the attacker is going to touch them based on the artifacts that we’ve planted in our environment.
So we’ve created an early warning system. If you’re interested in other types, of offensive countermeasures you should definitely check out offensive.
The actual book written by John and others. They have really great techniques that you can use to make your environment, environment less attractive to an attacker.
My tongue is just twisting up here at the end.
Jason Blanchard
You need a rest dave?
David Fletcher
Yeah, I need something.
Jason Blanchard
One of the questions out there was about are there multiple honey systems or is this just the accounts, the answer is you plant things throughout your environment. So obviously all these accounts are on active directory.
You might have ones on standalone hosts. We’ve got that one thing that does the, that expands out your web on your web server, right, where when you start scanning it, it just spider webs out to infinity, ties their scanner up and allows you to alert on that because it’s hitting it.
That book is full of different tips and tricks and places to lay traps.
David Fletcher
so, yeah, and the nice thing about what we’ve talked about here is it’s all, I mean, it’s all based on accounts that are zero cost in active directory.
so what I wanted to consider as I was putting this together were the default attacks that we all, try to execute within the environment.
And if I’m laying traps for you based on those defaults, then I increase my chances that I’m going to catch you. Obviously you should definitely address the preconditions first, because if none of these alerts are going to stop an attack, they’re just going to give you awareness that something’s going on.
So you want to prevent those things from happening in the first place.
Jason Blanchard
And John will talk about the ooda loop. Observe, orient, detect, act. Right. If you can detect earlier, then you have more of a gap to act. And that’s what this is creating. This is creating space for you.
There’s other ones that just tie the attacker up, that just slow them down. This is a trip wire. It alerts you that they’re creeping close to your front lines. Good stuff.
David Fletcher
And then the last thing is, I would totally encourage you to run all of the powershell tools that we talked about in your environment for yourself because, a lot of organizations that we look at, when we run powerup on their endpoints and we tell them, hey, you’ve got these privilege escalation opportunities.
Well, how do I identify and remediate these things? Run powerup. I mean there are about seven or eight different tools that I’m aware of that will do, windows privilege escalation, evaluation on a host.
Some are batch scripts, vbs, powershell. I mean you should definitely be using those in your, in your environment as you’re setting up your gold image so that you understand exactly what the attacker is going to see and remediate as much as possible.
David Fletcher
Awesome. Hey Jason, do we need to hand out some backdoors and breaches stuff where we do that post show?
Jason Blanchard
I will do a post show and then Dave, you have any final words before we kill the recording and do some post show banter? No. so the final words would be check out our conference, our blog, and follow us on Twitter, if you aren’t already.
and definitely keep an eye on the, cred, defense toolkit, repo, because I’m hoping to have, the provisioning tool out there within the next couple of weeks.