Good afternoon, everyone. I'd like to say that I'm between you and happy hour, but there's a couple more speakers.
Well, I'm excited to be here. Second, third, fourth time to EIC. I always love this conference, love to be around my European counterparts. So we're going to talk a little bit about securing identities and specifically around ITDR, which is a really hot topic. I'm going to focus on Active Directory today, though. Why when we're talking about IDPs and modern authentication and there's a bunch of other directories out there, why focus on Active Directory?
Well, let's just be honest. Active Directory is still a pretty leaky sieve when it comes time for identity security.
I mean, it's a 25-year-old technology. It has a whole bunch of not baked in security. Microsoft's patchwork did. I've done a lot with Kerberos in my lifetime, and they've kept pushing the envelope and the spec on Kerberos and doing things like armoring and hardening, and we keep trying to do it, but yet there's just always a vulnerability, a misconfiguration, and unfortunately, we've pretty much indexed all of our identity infrastructures around Active Directory.
Most of the customers that I talk to that are using Okta or Entra ID or anything else use Active Directory as a source of truth and then cascade everything else down to the other directories. So since it takes such a prominent part in the identity infrastructure, it's really important to talk about what can we do to harden that. And so my goal today and the next 18 minutes that I have with you is to give you a couple of what I'd call free strategies, things to think about, take those back.
Obviously, as a vendor, we'd love to talk to you about some of the things that we can do so you don't have a bunch of PowerShell scripts that you got off of GitHub trying to fix your identity security problem in Active Directory, but hopefully at least you can take some of that away and be able to use that and get further along. So, you know, when we talk about the different threats that are towards your Active Directory, all of those names should be familiar to you, like if it's the DC sync, DC shadow, so how are you impersonating Active Directory?
How are you pulling just wholesale dumping information from Active Directory? You know, are there all of the pass the hash, the tickets, the golden tickets, the silver tickets, all of the Kerberos vulnerabilities and threats that are out there? These are all attacks that are out there that are available for a bad actor to use.
You know, we have an entire catalog, so if you go to netrix.com slash I believe it's threat catalog, or you can just Google it, you'll see all of the different attacks that we have out there along with their MITRE attack classification and so you can get a better idea of what those are. I would encourage that if you don't have an ITDR tool and even if you have a SIM tool, you can find things like Sigma rules that you can put into your SIM so that you can find some of the stuff.
Again, we have solutions to help you with that, but be aware of these and be able to start detecting off of those because if you see any of those in your environment, there's a good indication that you've got a bad actor. I'm not going to go through a lot of the details of anatomy of ransomware, but this is a good idea of how you go from initial access via somebody finding a credential or using an initial access broker all the way through when you get actually to your lateral movement, your privilege escalation, and then on to great victory with data exfiltration.
This is a general way that attackers are trying to get access to data and if we're sitting right here in this compromised, I don't think that works, in the compromised credentials or in the privilege escalation, which is what a lot of these vulnerabilities do. What I want to do is walk you through a couple of these and help you with how can you not be the next headline in a breach through your active directory. A couple of problems with just identity in general as the attack vector. First of all, it is a proven attack vector.
We see a lot of ransomware gangs who were originally going after vulnerabilities on the endpoint who are just attacking the endpoint are now switching to identity. Scattered Spider is one that comes to mind. Scattered Spider has moved a lot more towards an identity attack than an endpoint attack. Why have they done that?
Well, it's honestly because EDR has gotten really good. I used to remember when we were here 15 years ago, we as the general collective security body, and we were talking about everyone just had semantic antivirus. I don't even know if it exists still. Maybe it does. I apologize. But now we've got CrowdStrike and SentinelOne and Microsoft Defender. For the most part, they do fairly well, even not super tuned out of the box. Now when we have always kind of moved to the endpoint as an attack vector or even the network edge as an attack vector, all of that has kind of gone away.
Either we've gotten better at it or we've turned to the cloud. Of course, what is that kind of key part of cloud security? The identity. So attackers are going after the identity. Next of all, identity threats can subvert traditional tools. If you think about like I help manage our IGA capabilities at Netrix as I run the product management team. Traditional IGA doesn't really address the problem with the threats that are happening on the identity. They can help with some of the posturing, but an IGA tool isn't going to detect or pass the hash and be able to lock things down.
So those traditional IGA tools and that posturing that we were doing all these years, which were actually more management and compliance functions, really don't act as that really silver bullet for preventing identity threats. Let's be honest. A lot of people have limited control and visibility. Even if you have a SIEM solution, there's a good chance that you're just vacuuming up Windows event logs.
Well, a lot of Kerberos issues, a lot of the pass the hash, that actually sits at a lot lower level. So you have to hook technologies like LSAS and other things to be able to get really good information as to what's going on in Kerberos and some of these more deeper technologies. You're not going to see it as a surface level. Microsoft bought a company that was doing it at the network level.
I think most of us as vendors now do a lot more hooking in the internals of Active Directory, but it's just not something that you're going to get if you buy and out of the, like if you go to Spelunk and get a SIEM tool, you're just not going to see that level of visibility. And then finally, as I mentioned before, moving to the cloud has really exacerbated this problem.
You know, it's great. If I go to the cloud, I don't have to worry about network security. I don't have to worry about a lot of things.
I should, I mean, in the sense that I need to make sure that the cloud provider provides that. But I don't, you know, now my onus comes down to the identity. It comes down to how am I protecting that identity? How am I putting the right policies and, you know, making sure that I configure conditional access and other things like that to make sure that we don't have those security challenges. So I'm going to give you three things to think about and give you some ideas. The first one is visibility.
So when you think about Active Directory, when you think about what do I need to do, the first thing is just take stock about what you have at Active Directory. Like, what are the objects? What is the state of those objects?
Like, if I came to you and said, if I ran a, like, there's really basic PowerShell cmdlets that will show you when was the last login. Are we going to see last login events on user objects that are hundreds if not thousands of days old that are still enabled? Probably not a good idea. So what's the state of your objects? What are the state of your attributes? What are the ACLs on your attributes?
Not very good if all of a sudden for some weird reason, and heaven forbid I've seen a lot of different misconfigured Active Directories, but you have a lot of attributes that are writable, including things like service connection points and other attributes that can be damaging or create things like even denial of service in Active Directory. But what is the state of those? Policy and sysvol.
Again, another thing to consider. And then your configuration passwords. Do you have passwords sitting?
I mean, the worst ones I've seen is putting passwords inside of the description field because you wanted to make it easy on your service accounts. Not a good idea, considering that all of those are usually world readable anonymously. And then on the activity, what is the activity, how are you monitoring the activity of Active Directory? Is it through Windows event logs? Is it through other things, and do you understand what the CRUD operations are? What systems are doing that?
Do you know the service account that your IGA system is using to write into Active Directory, and how are you actually protecting that? What are the other third-party products that you have or line of business systems? Where are those, and where are those passwords being stored, and are you using a secrets manager to do some of that? All things that you need to take stock of and understand the visibility. So three things I'll leave you on the visibility front. The first thing I would say is make sure that you discover the use of weak, compromised, and shared passwords.
There are open source projects out there that use Troy Hunt's Have I Been Pwned database, and you can go scan that and get that information. Now, they're kind of kludgy, and obviously I would be happy to share you what we do, but if you don't want to buy something today, you have the ability to go do that. There's no reason why you can't take a corpus of exposed passwords and run it through your Active Directory and see what is out there, which, just for everyone, the last gentleman that was here that was talking about NIST, is the NIST-recommended way of doing it.
We don't expire passwords anymore. We just monitor passwords for compromise. The next thing is to sever direct delegation. Delegation access of Active Directory is something that you should consider, especially if you're a large organization and you're not using a third-party tool to delegate that access. Least privilege for Active Directory management is something that all organizations should consider, especially if you're a large organization. The delegation capabilities in Active Directory are too coarse-grained to really do things that are not risky in your business, I would say.
So if you're doing native delegation inside of Active Directory, I hope you're documenting that, and if you're not, then you need to start looking and crawling through that. And again, there's tools out there that live in the open-source land that can help you with some of that. And then finally, identify accounts that have service principal name assigned. This comes down to Kerberos delegation.
So a lot of those Kerberos attacks, when we talk about constrained or unconstrained delegation and how you define those SPNs, those are things that you should be considering and making sure that you're taking stock of. On the prevention side, there's kind of two things. First of all, what's your policies inside of your Active Directory? How are you codifying that? What are your runbooks? How is the help desk?
If you're running hand-in-hand with your SOC, I know, again, as we've had ITDR conversations, the gentleman from IKEA yesterday was talking about making sure that identity and the SOC come together, and I highly recommend it. I have stories I can tell. If anyone wants to come afterwards, I can tell you some stories from my days in working for MDR vendors and what we did from an identity standpoint. But what are your rules? What are your runbooks? What are your playbooks? How are you codifying all of this?
Make sure that you are, this is just as much a documentation effort as it is a technology effort. And what's the policy? How are you actually enforcing this? You write all these policies out, and that's great, but do you have some sort of systematic policy? Do you have approvals? Are you using, for example, even your IGA system and approvals in that? Are you using ServiceNow? So that as these changes are happening and your change management is occurring, there's at least some sort of codification of that.
Again, top three things I would say from kind of a policy standpoint. First of all, blocking membership changes to privileged groups. So I hope that everyone that has domain admins, that has enterprise admins, schema admin, whatever admin, or any other privileged groups, that you've got some sort of mechanism to block that change or to at least have a dual control. So if you've got a PAM tool, at least make sure that if there's like, you really lock down who can touch those groups, and you have to go through even if it's just a traditional PAM tool.
Next is blocking Active Directory replication from non-domain controller accounts. So really, like, go in and hopefully you understand your topology. If you don't understand and you are seeing things like DC sync happening, first of all, if there's a vendor that tells you to do that, go yell at your vendor. That's not a good thing. But if you are doing that, then figure out why that's the case, and then make sure you disable that. And then what we would recommend, and there are ways to do this without buying a commercial product, but you try to use just-in-time as much as you can.
So even if it's just a more manual effort, don't give someone, we used to call them ADM accounts or an ADASH account, or whatever nomenclature you guys are using, but long-lived ADM accounts are just not in vogue anymore. So it's okay to have an ADM account, just don't have domain admin until you actually need it. And you'll hear, you know, you've heard a lot of vendors, even on the main stage, talk about that on how you should make sure that we're moving to a just-in-time methodology. And then the third one is recovery, and this is really important. I think this gets overlooked a lot, right?
Like we don't think about the, okay, what happens if I actually get popped scenario? What happens if I get ransomed and my domain controllers all get ransomed and now everything's been scrambled? Like there is really, if you ever want to read really sad IR reports and they're out there, go out and read the IR reports where they talk about how they had to rebuild Active Directory in a weekend because all their Active Directory got ransomed and they didn't actually have a backup. So that's under the malicious. There's also the accidental, right?
Like how often does somebody make a bunch of changes, especially if some of you are in M&A activity and over the weekend you're going to go do a really nice, oh, we're going to start merging forests together and we didn't take a backup and then something really bad happened. I'd put that kind of under the accidental.
Like, oh, oops, we didn't realize that that, even though we ran the tabletop exercise, we actually never was able to fully test and so we went and ran something and now we can't back the changes out because we had all of these problems. I hope none of you have to rebuild an Active Directory environment over the weekend. It's not very fun. So make sure that you're worrying about the backup and obviously, conversely, the recovery. You need to run, just like a backup of any really important server, you need to make sure that you're testing those, right?
You're restoring objects, you're making sure that they're sane, that those backups are working. And then on the level side, just make sure that you are grabbing all of the objects and attributes that are needed and you're doing a forest level. A lot of products will start to do domain-level backups. Realize that there's more to a Active Directory domain than just the domain. There's forest level information that you need to make sure that you actually pull in and so it is important to think about forest versus domain. So three things here to consider.
First of all, take regular snapshots of Active Directory, not one and dones. And again, there's scripts to do this. They're not great, but I mean, they're better than nothing. They get you out of a pinch if needed. So make sure you're taking regular Active Directory snapshots, a full backup of at least one full backup of a domain controller in a domain, and obviously store those in a secure location because those have all of the keys to the kingdom, right? All of the password hashes, everything. They're very, very, very sensitive. So make sure that you're doing that.
So really quick, just to highlight really quick, we do at Netrix have a set of AD security solutions, especially around ITDR. This just gives you an example of all the things that we can do, both agent and agentless. And so I would encourage that if you go through this and you're head spinning because you're like, wow, I don't have any protections on Active Directory and I'm really concerned and I don't want to go out into GitHub and see what I can do with PowerShell cmdlets, we obviously would love to talk with you. This is just one of the examples of our architecture.
And the three things I always like to say, hey, when you get home, what's your 30, 60, 90, right? I don't have a 30, 60, 90, but I do have three things to leave you with. First of all, we offer PingCastle, which most red and blue teamers know. It's a tool that's similar to also SpecOps or if you've heard of SpecOps.
It does a, you get your free Active Directory assessment. So it looks at the posture of your Active Directory and it gives you a bunch of suggestions that you can do.
And again, these suggestions, we point you to a bunch of Active Directory articles and Microsoft articles, but these are all things that you can take and you can figure out, or I mean, and you can take those and have a better posture of your Active Directory. The next thing is to go to our attack catalog.
Again, the attacks that are against Active Directory. Again, we're not trying to sell you anything. It's just a good way to go through and see what it is, the research around it, what's the MITRE attack classifications, everything that helps you talk security with your security teams. So if you're trying to, again, you're trying to bridge that like identity compliance view that we, a lot of us live in to a security threat hunting detection, this is a great catalog that you can go show a threat researcher that might be in the SOC and he or she will eat it up.
And then finally, you know, we invite you to look further at our solutions. We have, again, a variety of AD security solutions, along with data security and also endpoint security. And with that, I'll go ahead and turn it back over to Alexei and we can see if there's any... Thanks very much, Tyler. And we have a question, by the way. But feel free to give him a round of applause, of course.
Yeah, thanks, Tyler. Food for thought. Some of the techniques you mentioned there, do you think they would help with some of the NHI weaknesses that we've been hearing a lot about this week, the non-human identity stuff? You mean with some of the suggestions?
Yeah, the techniques. Are the threats there in the first place? Are you seeing that? And secondly, would those techniques help?
Yeah, I mean, you know, I would say that credential stuffing has no bounds, whether it's NHI or whether it's human. So, I mean, from a password standpoint, if you have a... Let's take passwords, for example. We all have that LDAP service account that has been created 20 years ago and it was put into production and everyone used it.
Now, there's a lot of problems with changing that password. But to your point, if you run through the credential database and that's an exposed credential, then that's something that you need to consider and there's logistics and things that you need to talk about. On the second half around NHIs, I mean, security, we always hear this, right? Defense in depth, right?
So, there's going to be a bunch of different things. Anything that you can do to improve the posture of your security of Active Directory is going to help whether a human or non-human account.
So, I would say, you know, there's a bunch of discovery and other things that you're going to get off of NHI tools and whatnot. But, yeah, like going through and saying, hey, we're going to pull back privilege from all of our accounts that shouldn't need privilege and move to just-in-time, that forces you to have that non-human conversation with your vendor.
Again, vendors, we are the worst at this, being one. I've been at places where we've had bad hygiene when it comes to that. Going through this will force you to have that conversation and maybe they fixed that problem, you just hadn't addressed it.
So, anyway, hope that helps. Okay, thank you very much again.