Hello, everybody. Welcome to today's Black Hills information security webcast. My name is Jason Blanchard, and I'm here with Caitlin and Alyssa. And they're gonna talk today about active directory act act damn it. Attack path in action.

So if you don't know how these webcasts come about is we reach out to all of our testers, all the people who work in the CPT, the SOC, all of our technical team, and we say, what would you like to share with the community? And a lot of times they take, like, hey. We we're thinking about adding this to the class. We want to have or have additional material or something like that. So Caitlin and Alyssa work together in our continuous pentesting team.

They think about how to attack organizations all day every day, and they are fantastic at it. I hear they talk about side quests from time to time where they, like, find a thing, like, let's go ahead and dig into that thing. And so it's cool to see how their minds work. It's cool to see how their, research comes together. And I think they're incredibly delightful and witty and awesome people.

So, hopefully, during this webcast today, this brings you joy, teaches you something you never, knew before, and you can now secure your organization in a way that you did not think you needed to. Because, generally, that's what happens. You watch these and go, damn it. And so, hopefully, you have one of those moments today where you can go and fix that. And with that, Caitlin, Alyssa, good luck.

I'll be back at the end for q and a and, for other things. Have fun.

Okay. Cool. Alright. So the thing about screen sharing is that I can't see Caitlin, and I am, very dependent. So I don't I can't see your face for reassurance.

So today, as Jason said, we're gonna talk about an Active Directory attack path in action. The reason why we're doing this webcast is because we want to show some of the common issues that we see on different test types and demonstrate how seemingly insignificant misconfigurations can really snowball into critical issues in your environment. Okay. So before we get started, just as a quick introductory to us, here are some fun facts about Caitlin and I. I much more enjoy sharing fun facts about Caitlin than myself, but we are each anti SOC or continuous penetration testing team testers here at BHIS.

We also are both anti siphon instructors. So we teach an assumed compromise class that we talked a little bit about in pre show. Caitlin and I specialize in assumed compromise testing over at on the anti SOC team. And Caitlin also specializes in cloud testing as well. A brief overview of some of the stuff that we are going to talk about today.

So we're going to start off with network access without credentials. And then we're going to walk through the process of discovering what resources, systems, services are accessible to us. We're going to identify a vulnerable service and exploit that service to gain domain credentials. Once we have domain credentials, we're going to demonstrate how to we're going to enumerate the domain. And we are going to look for a path for privilege escalation.

And then we'll talk about some defensive considerations that can help remediate these sorts of issues if you do see them in your environment. Cool. So initial discovery. So once again, we are on a system in the network. We don't have any credentials.

So one of the first things that we'll do I mean, depending on what kind of test you're on, maybe the customer gives you a list of systems in scope. Either way, you want to determine which systems are live and what services are accessible. So we perform like a port scan to do something like that to get an idea of what services are available to you. For web services, we can use tools like GoWitness or EyeWitness. These are screenshot tools.

And they do things like fingerprint the infrastructure of the underlying of the web service. It's a good way to get a visual overview of the web services that are available because, let's say, you have a ton of web services in your port scan results. You don't have time to manually navigate to each one and to try to prioritize. So that's where tools like GoWitness and iWitness become really useful. To give an idea of what that would look like, here's an example of a screenshot taken using GoWitness.

So GoWitness and EyeWitness can each intake either a list of files, a single target, or scan results from your port scanner, your vulnerability scan results. So this is a screenshot taken by GoWitness. In our target environment, we found a Jenkins instance. If, for those who are not super familiar with Jenkins, it's, an automation server used for CICD. And oftentimes, it's a valuable target for attackers because in order to carry out some of the in order to function the way that it needs to, it requires access to interesting things in the environment.

So sometimes there will be credentials stored in Jenkins. And if the system is not hardened, it is accessible to someone, you can obtain you can obtain these secrets and access to sensitive information. So based on this screenshot, we can see that it looks like Jenkins is not protected by authentication. The reason why I say that is because you could see the builds, the build history in jobs. So we see that there's a Jenkins service on one zero point zero point zero point zero on Port 8080.

So once we've identified a service of interest, we would investigate that service. To investigate this particular service, we could use a tool like Jenkins Emth Hunter. This is a tool that was written by Kent, and it has two main scripts. The first script checks for authentication, which we did see that there wasn't it didn't enforce authentication. But if you didn't know, you could feed this tool a list of Jenkins servers as well, and then it will check each one.

So as you can see right here I'm not sure if you can see my cursor. But as you can see right here, we can. Cool. Authentication is not required. Next, you can use the Jenkins m hunter script, which will enumerate different jobs and build history and look for sensitive information.

So you would do that by passing that whatever Jenkins instance you wanna target. And similarly, you could pass a list of posts as well. We have okay. So once we do that, we see that in the build image weekly job, which just for funsies, we saw right here, we found in different build history, we found different environment variables. So these three environment variables in the center are Jenkins specific.

And for the purpose of this webcast, we're not going to focus on Jenkins. We want domain access, so Active Directory domain access. So we see two users here. We have this Active Directory user, and we see this credential winter twenty twenty five. And then we have this other account here.

We have enumerated services that are available to us in the environment. We've used GoWitness or similar tool to identify a web service to poke at. We found an unprotected web service that gave us credentials. And now we are going to try to determine if these credentials are valid on the Active Directory domain. And so in our port scan results, not only did we find a web service, but we also saw that this IP address, one nine two point one six eight point two point four, is running Kerberos, has LDAP and LDAP S ports open.

So we are assuming that that is the domain controller in this environment. So we're gonna test our credentials against that domain controller, that artifactory user, and the winter twenty twenty five using NetExec. NetExec is a tool used to exploit network different network services, and it's often used in for different post exploitation activities as well. So we tried to authenticate with this artifactory user, and we were unable to authenticate. We got this log on failure.

So although we did we weren't able to authenticate, we could try to test for either similar passwords or try to to to test for password reuse by spraying this password across a list of users. In this case, we don't have a list of users because we do not have domain credentials. So one way we can obtain a list of users is through recon that can be done externally. We can look for emails and try to identify username conventions. Once we have identified the username convention, let's say it's first dot or first last or first Dot first NameDot last name, we identify the email pattern, and then we wanna create a list of potential usernames.

So there are various ways that we could do that. One way is to use for for our example, we used a repo called statistically likely usernames, I believe. Cool. So statistically likely usernames is a repo that has a bunch of common, like, first name, last name combinations, and then it also has a bunch of different common patterns. So we'll it has those lists set up for you, the first, last, or first, out, last, etcetera.

So we use the list that corresponds to our naming convention. And then we are going to attempt to identify valid usernames. So to do that, we can use, like, a guess and check method. So essentially, we're just going we're just going to iterate through our list, and we're gonna use a tool called Kerberoot to do that. Kerberoot uses tries to authenticate over Kerberos.

For the for username enumeration, it uses Preos, so we don't run the risk of locking out accounts during this username enumeration phase. So we have our list of users. We stored that in this potential dot TXT file. We're gonna run Kerberoot, the user enum module. We're gonna pass the domain, which I failed to mention we did we were able to determine here.

So once we authenticated to tried to authenticate using the Artifactory user, we we found the domain. We could have also seen that in other using other methods of discovery. But we passed the domain, the Active Directory domain, and then we passed the DC IP address that we discovered previously. So this is what it looks like with our running our username enumeration, and we found a few valid usernames. We're going to use these valid usernames and perform a password spray using that winter twenty twenty five password.

And so we are also gonna use Kerberoot to password spray. We're gonna specify the password spray module. We're gonna pass the domain. We're gonna pass the DC IP address and then the list of users that we discovered from our username enumeration and that password. And as you can see here, we found three users with valid with that use Winter2025 as their Bang as their password.

So now we've gone from network access to at least, like, three sets of domain credentials.

So now that we have our domain credentials, we're gonna move on to enumerating the domain. So we we have a foothold in the domain with these credentials for these users that we found, but we want to identify ways that we can move laterally or escalate our privileges within the domain. So the one of the most useful tools for doing this is Bloodhound. So Bloodhound is a tool that you collect data from active directory, and you put it into a Neo four j database. And Bloodhound displays all of the relationships between the objects in Active Directory, so things like users, computers.

It it will enumerate Active Directory certificate services, and it puts everything into a graphical format. So it's really easy to identify these these chains of attack paths. So whereas if you just are looking at the standpoint from a single user, it's kind of hard to see, okay, how do I get from this user to, you know, domain admin or to a different privileged account or to a different machine? And Bloodhound allows you to do that because you can look at it visually and it also allows you to, select this is the user whose credentials I have and this is where I wanna be. Are there any paths from my point a to my point b?

So to collect our information, from the domain, we're gonna talk about four different ways to collect this information. They're all pretty much gonna collect the same information. Some of them grab a little bit more than the other ones. But regardless of which way you're able to execute it, it's going to be useful for you. The first one that we're gonna talk about in the next slide is NetExec.

So NetExec actually has a built in, Bloodhound collection module, in the LDAP protocol section. So this is really simple. You're gonna do your net exec. You're gonna say we're gonna use the LDAP protocol. You're gonna provide it the IP address of your domain controller, and then we're gonna provide those domain credentials that we just found.

We're gonna provide the bloodhound flag, and then we're going to say that we want to collect all of the information. So there are different types of information that can be collected by bloodhound and or by these different collectors. And some of it, the collection is more stealthy than others. So sometimes you might not want to collect everything. Sometimes you might just wanna collect like a subset that isn't as loud, like if you're if you're trying to do a more stealthy enumeration.

So then the next tool that we could use to collect this is bloodhound. Py. So bloodhound dot py is based on the the official bloodhound collector, but it's it's built in Python instead. And this can be useful because you can run this from a Linux machine. So if you have, let's say, like a a Linux implant or if you have, your proxying, traffic into the network from a Linux machine or maybe you can install Python on a machine in the network, this is a this is a useful tool that you can use for that.

So in this case, we're just gonna run bloodhound.py, and we're gonna provide our username and password. We're gonna provide our domain, that DOAC lab. One thing that we didn't put in that example command at the top is that NS flag. That's the name server. And then tax c is that collection method similar to how we did with NetExec.

And in this case, we're selecting to collect all of the information that we can. So if you look at the, the output there, you can see it's connecting to the d c o one, the LDAP server, and it's enumerating all of that information, the domain, the computers, the users, the groups, and so on and so forth. So the next way of collecting this information is using SharpHound. So SharpHound is the official, BloodHound data collector. So this is this is the tool, like, from SpectroOps.

It can be ran, from a from a Windows machine. It's a it's a c it's built in c sharp. And this can be really, useful if you have access to a domain joined workstation, but maybe you don't actually have, like, you don't know the plain text credentials. Because if you run this from a domain joined workstation, it will actually run-in the context of the currently logged on user. So you don't have to provide that username and password.

You can just execute SharpHound and then same thing in this case, the taxi is the collectors you wanna use. So all you have to do is run SharpHound and we're gonna specify we wanna collect all of the information and it'll automatically run-in the context of the the user that's authenticated on that machine. And then the last one that we're gonna talk about, this is one of my favorite ones. This is actually going to be utilizing a legitimate tool that is published by Sysinternals, and the tool is called Active Directory Explorer. And it can be downloaded or ran directly from the Sysinternals website.

So, like, live.sysinternals.com. Whenever you download it, you can see on on the right side, this is what the the GUI looks like. You can, connect to a domain. So there are multiple ways to connect. You can either provide like, this is the domain controller I wanna connect to, and these are the credentials I wanna use.

Or similar to how whenever we we showed SharpHound in the previous one, If you are running this on a domain joined machine, you don't have to provide that information. You can just select that you want to collect or you want to connect, and it will automatically connect to the domain that the workstation is associated with and use the credentials for the currently logged in user. So this is another way that's really useful if you have access to a workstation, but you don't know the credentials. The way that we collect the information here is Active Directory Explorer has the ability to take a snapshot of the entire database. So that's what you can see in this screenshot on the right here.

Step one right there is that little floppy disk button. So that's what you click on to say that we wanna take a snapshot. And then, step two is the the dialogue that pops up that asks you, like, where you wanna save it, and what you want it to be called. You can also throttle the utilization down here at the bottom. So see how it's a 100%, right now?

This will make the enumeration slower, which is good because it's not creating as much traffic like in a short period of time, but it also, of course, will take longer. So you have to wait longer for it. So then once we collect that data from AD Explorer, there's a tool called AD Explorer snapshot dot py. This tool converts, snapshots from AD Explorer into a format that is ingestible by Bloodhound. So whenever you use AD Explorer snapshot, it's going to take that DAT file that you collected and it's going to convert it either into Bloodhound adjustable JSON files or the default behavior now is it's going to export this in a export the the data in a log file that we can then pass to BoFound, which we're showing in that, next slide.

And whenever we pass that log hound, that log file to BoFound, we're gonna provide that as the input. You can see that tack I switch there, and then you got the tac o output dir. And then in that output directory, it's going to it's gonna parse all of the information in that log file, and then it's going to output those Bloodhound ingestible JSON files into, that output directory that you specify. This is also, the the Bobhound method as opposed to blood or a d snapshot a d explorer snapshot dot py also has the option to directly convert that information from the dot DAT file to the JSON files. But in recent engagements, I've had issues with this method where, there's a lot of, like, SIDS that don't get resolved using the Baughhound method.

I haven't been running into that that problem. So this is this is a a cool alternative way of converting those files and an alternative way of of collecting things using a tool that is is typically seen as a a benign administrator tool. So then once we collect those files, we're going to import them into Bloodhound. So the actual, like, setup of the Bloodhound, the GUI in the Neo four j database and all that is outside of the the scope of what we're gonna talk about here. So we're just gonna say that, like, we've already got that set up here.

So then whenever we, we open up our GUI, we can just take those JSON files that we that we have from whichever collection method we used, we can drop them into Bloodhound and it's going to it's going to build the that graphical database with all of those relationships inside of it. So if you look on the right side here, you can see we have that little tab selected called Cypher. Cypher queries are what are used to query the back end database, and there are several Cypher queries that are built in to Bloodhound that are are really useful. And so you can see a snippet of some of them here. So some of these are just listing like, oh, I want the domain admins, or, I want to know who has DC sync privileges, things like that.

There are also some Cypher queries that are built in that will show you that will show you attack paths too. In this next slide here, you can see an example of, what one of those queries would look like. V Lewis, that's one of those users that we identified the credentials for earlier. So within Bloodhound, you can mark a user as owned or, a machine account as owned. So those queries will use those objects that you have owned to determine what other things you can reach.

So in this case, can see that we, we owned v Lewis based on that little skull, marker down in the corner, and, we used a query here that is showing the, outbound control that v Lewis has over other objects. So in this case, the result that we got is that v Lewis has generic right and generic all permissions over this workstation five machine. These rights, having these rights over a machine account, they enable, several different options for, attack paths. But we're going to talk about one attack path today, and that is resource based constrained delegation. We currently if you go to the next slide, Alyssa, we don't currently have a local account for workstation five.

And actually, like, in our our specific case, we don't we don't have sessions on any workstations. So because our compromised user has write permissions to this workstation, we can potentially perform resource based constrained delegation. So a really, really oversimplified, explanation of this technique is you have, two services. Any service can request a service ticket that is scoped to itself for any user. So if we have service one and service two, service one can say, hey, this domain admin, they authenticated to me, and, I want a service ticket for them that scoped to me.

Service one is doing that. So now you can have a second service. We'll call it service two. And that service can say, hey, this other service, I'm gonna allow them to delegate for me. So they can request tickets on behalf of other users that are scoped to me.

So we have a first service that can request service tickets for itself, and then we have a second service that is allowing the first service to request tickets to access it. The way that that second service is going to say, like, hey, this first service, is allowed to do this is by setting a an attribute in the active directory object that is called MSDS allowed to act on behalf of other identity. Now it's a really short, easy to remember attribute. So by adding that that first, the account with that first service to that attribute, that tells the, the KDC that that first service is allowed to do this for the second service. Because we have those write permissions on workstation five, we can potentially perform this against workstation five because we can write to that property on workstation five, and we can add a computer account that we control to that property.

We can add our computer account that we control and and make that service to say, alright. I I trust BHIS's computer account to to grab these tickets for me. But the key here is we have to we have to have an account that that second service can that we can use to delegate to that second service. So one of the ways that we can do this is we can see if we can just create a computer account. If we go to the next slide, we are querying the domain for the machine account quota.

And by default, the authenticated users group in Active Directory has the rights to add workstations to the domain. And by default, the number of workstations that the users can add to the domain is 10. So in this case, we are using NetExec, and we're we're checking to see what that number is set to in this environment. So NetExec, we're using that LDAP, protocol again, providing the DCIP or username password, and then we're using that MAQ module, that machine account quota. And looking in the screenshot, you can see that the machine account quota for this domain is set to that default value of 10.

We know that we can create a computer account. So this next slide, this is this is the most complex slide we got going on here. But this is showing the steps that we're gonna take, in this exploitation. So if you look in the middle where we've got our cute little, start here guy, the first step that we're gonna do is we're gonna create that computer account using our domain credentials. So in our case, we're calling our computer account Snow Machine.

So then step two, if you look above the domain controller over there, now we're going to use our account that has right privileges to workstation five to add Snow Machine to workstations workstation five's MSDS allowed to act on behalf of other identity attribute. Then once we do that, Snow Machine is going to do, those two ticket requests that we talked about before. So first, it's going to request a service ticket that impersonates DO admin that is scoped to itself. And then after that, it is going to use the s four u to proxy protocol to request a service ticket for DO admin that is scoped to workstation 5, which it is now allowed to do because we set up that delegation property on Workstation 5. So if you look down below the domain controller, there's that step six there.

So this is that step where the the KDC is gonna check, and it's gonna see, like, alright. Snow Machine is requesting this ticket. Do they have the ability to do that? Are they in that MSDS allowed to act on behalf of other identity attribute for workstation five? And since we added that value in there, it is.

So we get our service ticket, and then we're over here on Snow Machine. We got that service ticket, and now we can use it to authenticate on workstation five on behalf of the user that we chose. So in this case, we chose the DO admin user.

How crazy does it drive you that that's on the next? Does that doesn't

Oh, it's oh, oh, it drives me absolutely insane. Yeah. The the word wrapping. Yeah. Yes.

I am, for everyone's, information, I am the one who is in charge of formatting our slides. So, you know, that is is driving me absolutely insane.

I need you look at the screen sharing. Okay?

Uh-huh. Uh-huh. Also, just so everybody knows, Alyssa's really taking one for the team here because my Zoom crashed earlier, and she is sharing the slides on her single screen that she has. So she does not get to see me, and she does not get to see, any presenters' notes or anything. So she's y'all yeah.

I give her some applause. She's doing great. Anyway, and back to the show. So now we're gonna walk through, like, practically how we're gonna carry this out. So the first step, we're gonna create that snow machine computer object.

So we're going to use an MPacket module called add computer dot py. MPacket is a Python toolkit, and we typically use it for post exploitation activities. And it it can be used to abuse different, network protocols. So in this case, we're gonna use the, add computer.py, and we're going to specify the computer name as snow machine. We're going to specify the password we wanna use.

We're gonna specify the domain controller IP address and then, our domain credentials, which in this case is that v Lewis account. So you can see that little boxed in bit in there. We successfully created that Snow Machine account on the domain. This next thing that we're showing, this finddelegation.py, this is going to look in the domain to find any delegations in the domain. If you look at the results here, the only delegation that was found in the domain is the domain controller, and it has unconstrained delegation, which is expected for a domain controller.

But that's the only one that exists in this environment. Our next step is we're gonna change that. Now we're going to use this rbcd.py, which is also, an Impacket, and we're going to use that to add our snow machine to that MSDS allowed to act on behalf of other identity attribute for workstation five. And we're gonna do that using that v Lewis account because v Lewis has right privileges on workstation five. We're doing rbcd.py.

We're giving our domain credentials for that user with the right privileges. We're saying we're going we want to be able to delegate from our machine, which is Snow Machine, and we want to delegate to, the target machine, which is workstation five, that w s o five in our case, and then the DCIP. So we ran our rbcd.py command, and then you can see that box in the middle. Snow well, Snowmachine can now impersonate users on workstation five via s four u to proxy. It shows you the accounts allowed to be hacked on over that whole, you know, long string thing.

And, Snow Machines, SID is now in that property. So now if we do that same find delegation dot py, that we ran a second ago, we see another delegation exists. For Snow Machine, we got that resource based constrained delegation to Workstation 5. This is, this isn't a step in the exploitation chain. This is just like a a demonstration showing you another way to query that, MSD is allowed to act on behalf of other identity property and show you what it contains.

So we did get a d computer, and we grabbed that property from Workstation 5. And then if you look at the bottom, can see that whenever we expand that property, that access has Snow Machine allowed in it. So now we're going to select our target account. So this is gonna be that account that we are requesting those service tickets for. So these service tickets can, impersonate this account.

The the, you know, top end prime target here, domain admins, we're gonna take a look at these guys and we're gonna target one of them. One thing to consider, and also this is, this is within Bloodhound, this graph. So this is whenever you select that that first query that, was in the screenshot previously, the showing the domain admins one, this is what is shown by that. We've got all these options for some domain administrators that we could choose from. But another thing to consider on the next slide is that we need to avoid choosing anybody who is a protected user.

So there is a property that can be set on an object that is called this account is sensitive and cannot be delegated. If either that flag is set on an account or if the account is in the protected users group, you cannot you can't, abuse this delegation. So whenever you add a a user to the protected users group, it automatically sets that this account is sensitive and cannot be delegated flagged. So in this case, if you look at the bottom, you can see Ivory Gould has, that little diamond, showing that it's it's a high value account, and that was one of our domain administrator options in the previous slide. So we know that we're we're not gonna be picking ivory to target.

So in the next slide, we're going to show getting that service ticket for workstation five. So you can see that in our screenshot here, the user that we chose to impersonate was d o admin. The this is also another m packet module that we're gonna be using, get st, get service ticket. We're specifying the service principal name that we want to get that service ticket for. So in this case, we're specifying a built in service on that target workstation.

So the the SIFs service on workstation five. And then we're specifying, that tack impersonate. So this is the user that we want that ticket to to be for, and then we're giving those usual, like our DCIP. And then we're providing that computer that has those delegation privileges. So if you look in the screenshot here, you can you can see those steps that we talked about.

So we're impersonating DO admin, and that requesting s four u to self, that's, requesting service for user to self. That is the request from Snow Machine saying, hey, I want a ticket for DO admin for myself. And then that next request, that s four u to proxy, that is the request from Snow Machine saying, hey, I wanna get a service ticket for DO admin for the workstation five service that I'm allowed to delegate to. And then at the bottom, we can see that we got a ticket for DO admin for SIFs on Workstation five, and that is in a credential cache file. So on the next slide, this is an example of what would happen if we attempted to do this same attack, but trying to impersonate a user that is in the protected users group or a user who has that, this account cannot be delegated property.

So we try to impersonate Amanda Nichols, which is one of those protected users. And you can see our big error that's boxed in there that we we can't do the delegation. So now we're going to show that this ex escalation was successful. So we're gonna take that that c cache file that we got from the previous step, and we're going to save that file to the Kerberos credential cache variable. And then we're going to use WMI exec, and we're going to drop into a semi interactive shell with WMI exec.

And in the WMI exec command, you can see the tack k option. That is saying that we want to use Kerberos authentication. And then the no pass option means that we don't wanna use a password to authenticate. So whenever you provide that tack k, it's going to pull from that k r b five cc name variable. So it's gonna use that c cache file that we put in there.

And then at target is, you know, where you where you're trying to authenticate to. So in this case, it's our workstation five. So after we, successfully established that shell, you can see that we ran whoami, and we are the DOAZ lab, DO admin user. So we're that domain user, DO admin. And then if we run host name, we can see that we are on workstation five.

We use this net command, and we can we can enumerate the local administrators group on this computer. So we successfully have the ability to authenticate to workstation five in the context of the domain DO admin user who is a domain admin. So one thing that you can do with these privileges that we now have is we can dump the local secrets on that machine. So we're gonna use NetExec for this, the NetExec SMB protocol. And we're gonna specify our target, which is that workstation five, which in our screenshot it doesn't show, but that two dot five IP address is the IP address for workstation five.

And then again, we're going to specify that we wanna use that Kerberos cache for authentication. And then we wanna dump the SAM database and we wanna grab LSA secrets. If you look in our output here, we got all kinds of juicy stuff from dumping those secrets. So if you look at the top, we got we dumped the SAM table from this machine. So those four accounts up there, DO lab builder, guest, default account, those are all local accounts on this machine.

Now, something interesting whenever we look at this is that DO lab builder, that built in administrator account on this machine has the same username as one of the domain admins that we saw earlier. There's a possibility here that maybe maybe those accounts are connected, maybe. We're going to try something based on that hunch. We're gonna grab that NT hash from DO lab builder that we just grabbed with that local secrets dump. And then if we go two more slides, we're going to attempt to authenticate to the d o lab builder domain account using that hash.

We can see that that domain account uses the same credentials as that local account. So we've got some credential reuse going on here, and we can use that credential to we are dumping the ntds.dit. So this is all of the hashes for all of the domain users in the domain that we're able to dump with this. So at this point, I know this is, this is pretty much game over. Semi queue.

That's your queue. That's your queue.

You know, sometimes I'm not that good at picking up cues. Alright. Okay. So to summarize our attack path here. We started out as with access to the network.

For example, we were on a Linux system. We did not have any credentials. We performed some enumeration of accessible services and found an unprotected Jenkins service. In this example, it's Jenkins. Right?

But something that we see frequently on network tests are internal services that are not hardened. So we see missing authentication a lot. So it's not the the purpose, I guess, that I'm trying to emphasize here is that not we don't need to focus on a Jenkins specific issue, but that it's an unprotected web service found on the internal network. That gave us credentials, and we reuse the password obtained from one of those accounts in a password spray attack and obtained a access to a domain user. So there are a couple issues here, right, like weak password policy and and password reuse and and whatnot.

Once we obtained domain credentials, we performed domain enumeration and analysis and identified an attack path where we found an object that we can control, which was that workstation. And then we saw that the default setting was set on this domain, so machine account quota was not zero. And therefore, we could create a computer object. With that computer object, we were able to abuse RBCD and set delegation from our computer object to that Windows workstation. And so that means we were able to request service tickets that were valid for that Windows workstation as anyone.

And so we chose to impersonate a domain administrator. Once we gained access to that Windows workstation, we dumped the secrets on that workstation and found the local RID 500 DOLab Builder account. And because those usernames were similar or because this username is the same username as the domain admin user, we also tried to pass the hash and test for password reuse on that account. Password reuse is is a common thing that we see, and it's these are this is really just to demonstrate how all of these little things, default settings, misconfigurations, or little web services that aren't hardened. There were only two builds two jobs in that vacant Jenkins server.

So it might not look like a high value system, but that little little information that that we got from that Jenkins server went a long way. Okay. So defensive considerations, things you know, I talked about some of some of the issues here. But internal for internal web services, make sure that they require authentication. Ensure that only users that require access to that service have access to that service.

Keep software up to date. So in this particular situation, we didn't necessarily abuse vulnerable and outdated software, but that is also a theme that we see frequently. Practice or principle of least privilege. So set the machine account quota to zero. Not every user not every domain user should be able to add a workstation or create a computer object for your Active Directory domain.

Only allow users to access resources that they are that are necessary. And then ensure that access is removed as users leave or roles change. Resource based constrained delegation ensure ensure that administrators and other sensitive accounts are added to the protected users groups or have and have the account as sensitive cannot be delegated configuration. Password policies require that passwords are 15 characters at least and disallow common commonly used guessable passwords like season year, organization name, welcome to organization, things like that. And then regularly audit and rotate your passwords.

I was I wasn't expecting Caitlin to change the slide because that's usually what happens. Okay. So earlier, mentioned that Caitlin and I are both anti siphon instructors. We teach this assumed compromise class. We cover assumed compromise testing methodology and detections.

And the flip side of that, if you are worried that you see these misconfigurations in your environment, you could also take Jordan and Kent's class, which is an active directory security hardening course. Each of those courses are taught at Mile High Hack Invest. I guess shameless plug here. So I have a link to that in the slides. Mile High Hack Invest.

Come see us at Denver. Assumed compromise. Our class is linked here just on the anti siphon course site, and then so is Jordan and Ken's class. All of the tools that we used are linked in the slides as well. And then this link has additional resources.

So it goes to a publicly accessible GitHub repo that has links to all sorts of stuff, like event IDs to detect certain activities, additional webcasts or blogs or and whatnot that are related to some of the topics that we talked about or other topics. They are not all just our blogs. They are just things that we found useful that are also included. And, it is okay to side to side quest, Caitlin. It okay to side quest.

It is not okay to make the side quest the main quest.

Even someone even say it's recommended to take side quests.

But but but we should also accomplish the main quest.

You know, a side quest now is a main quest later.

That does tend to be the case. Fun fact, Caitlin went on a side quest, and we changed the slides, like, at like, two minutes before we dialed into this webinar here today. And, you know, it's it's better for it. But does anyone have any questions?

Oh,

Good job, guys.

You did

Hey, everybody. Before questions, if you haven't checked in yet for Hackett, please go ahead and do so. Also, there's gonna be a free CTF today. Zach will be here in a second, and he'll explain the free CTF. So if you're like, hey.

What if we take some of the stuff we just learned and we can do a free CTF, and then there's, like, a prize by doing the free CTF? So we'll go ahead and do that. And, Caitlin and Alyssa, great job. But before we move on, great job. Well done.

Thank you so much.

Good job, guys.

The feedback I was seeing in the Discord chat and stuff was fantastic.

So

we'll take a look at the questions here. Deb, won't you?

I just wanted to comment that Ryan said it's a slide quest.

Awesome.

That's why Jason hates them. Questions. Yeah. If we missed your question, go ahead and plop it in the Discord, and we will ask these lovely ladies.

And, Zach, could you please introduce the CTF to everyone where they can find the resources? And then, we'll start with the q and a.

Okay. Yeah. Absolutely. So I'll put a link for, the CTF in the slide resources channel out on Discord. But you can just go to blackhillsinfosec.com/weekly-ctf.

It'll take you right to that page there. And there's a Monday form there that you'll need to fill out, then we'll have some questions. And Caitlin and Alyssa put together the CTF for this week. So good luck y'all. We will be picking winners next Monday on the Black Hills InfoSec Monday talking about the news.

So stay tuned if you, participate, and we'll be giving away a one, full on demand subscription. So, you'll get access to the entire anti siphon on demand catalog, and then we'll also be giving away one class of your choice from anti siphon training. So good luck

to you. Where's the link at? I put the link in the Zoom. So it's also on Discord, but I put it in Zoom too and Zoom Chat. If you go to the Zoom chat too, you'll see that we're giving away the new infosex survival guide, orange book incident response edition.

Orange. Are you glad? Banana. So alright, Alyssa and Caitlin. Let's do some q and a.

And then if you are interested in doing business with Black Hills information security, when this webcast is over, Brian Strand is here, and we'll talk about what it's like to be a continuous pentesting client of ours, where we spend a long time continuously doing a pentest on your workstation. So first question, if Mac is set to zero and protected users is enforced on all privileged accounts, what alternative paths could an attacker take to achieve the same outcome?

Will you say that second part one more time?

If MAC is set to zero and protected users is enforced on all privileged accounts, what alternative paths could an attacker take to achieve the same outcome?

One attack path that or actually two attack paths that we considered doing. One we considered doing and one is just another attack path for this webcast. One is that you with that write access that we showed previously with that v Lewis account, you can actually write directly to the workstation's MSDS key credential link attribute, which is to to put things really simply, that is where alternative credentials are stored. So if you use something like Windows Hello, you would have credentials stored in there. So you can use that to be able to gain the ability to authenticate to that machine using a credential that you write to their key credential link attribute.

That was a little that was a little detailed, but I I don't hopefully, helps.

Okay. This question, is content like this and your previous presentations representative of what your assumed compromise course is like?

Yes. Like, it's a real

fun thing. That's not a JSON question. That was a real Okay.

Look. I was just waiting for Alyssa to answer. I was trying to

give her the We were trying to see who was gonna answer. That's what was happening. Alright. I'm I'm assuming Caitlin rolls today, I guess. But we do cover a lot of the topics that we cover in our webcast also in the class.

And the webcast, we will cover so for every attack that we demonstrate, we'll show how to detect and how to remediate the issue as well or talk about considerations on how to remediate the issue. Does that answer that question?

Sure. Cool. If you can't answer it, then no one can answer it.

Alright. So we're gonna do a little wrap up just so that we can finish on time. And then we'll do some extended time for q and a. But, Deb, what what do you have?

Oh, I just had a question. We can you can wrap.

Okay. Alright. So I always like to do a final wrap up, and then then we do extended time. So, Alyssa, in to the loud keyboard there, Caitlin.

Is it Caitlin?

Oh, I'm so sorry. I'm so sorry. I'm trying to answer questions over here. Jeez.

You're an

insanely fast typer. It

is Wow.

Clicky. Clicky.

It's more satisfying that way.

I agree. Alright. Alyssa, if you could sum up everything that you talked about today and one final thought, what would it be? And then Caitlin will do the same thought.

It would be sometimes the simple things that we think are insignificant are lead to things that are critical issues.

Caitlin, if you could sum up everything you talked about today and one final thought that's different than Alyssa's thought, what would it be?

You know, I I feel like this is where, know, you Chris was saying earlier that he needed to jump on the two instructor train. I think this is one of the one of the downsides of the two instructor, train is that whenever you both get asked the same question, the first person gets to do the real answer, and then the second person has to come up with something else. So the takeaway for me I don't know. I don't know if this is necessarily a takeaway, but it is something along the lines of, like, persistence. So we showed one, like, very specific attack path.

There are so many other attack paths that are are just, like, very similar, like, little little chained things put together. Even if, like, you know, these specific techniques that we showed here don't work, keep keep looking for other other chains, other links that connect to each other. In this webcast, we showed that one complete successful chain. But, you know, sometimes you start here and you start doing a chain and then it it doesn't pan out. And then you start trying a different one and that doesn't pan out.

Or you try this one and then it forks and you try this fork and that one doesn't work and but eventually, you know, you'll you'll get there. You'll you'll find something. You just gotta, you know, side quests. Side quests are my they're my thing. They're my jam.

Alright. Thank you so much for joining us today. If you can stick around for a q and a, cool. If you wanna learn what it's like to do business with Black Hills information security, also stick around for that too. Alright.

Alright. We are in post show banter. Caitlin and Alyssa, thank you so much. For the people who have like, to the eight yes. You can type all You can type down.

All you want to.

I'm so sorry. I'm so sorry.

To to the 100 people who got the survival guide from today, thank you for trusting a link to the Spearfish General Store. Thank you for placing your first order where you have to give up your user. No. You're you're you gotta give your, address. And so we know that that takes trust, we appreciate the 100 of you that have done that so far.

If the rest of you would like to do it, you can go here. If you get a four zero four error, it means we cannot ship to your country. So we're gonna put in the how to get it for free there to download. We don't have, like you don't have to give us your email address. You don't have to do a paywall.

We don't have to do that sucks. We don't want it to do that to you. The only reason you have to give us your information for the physical copy is because it has to get to you somehow. Alright, Brian. So one of the things that Caitlin was talking about as we were wrapping up, and we'll see if we can answer some more questions here.

But I wanna get Brian in here about continuous pentesting, our anti sock service. Like, right, there's the sock, and then there's an anti sock, which just attacks you all the time instead of defends you all the time. Caitlin mentioned on the way, like, as we were ending the webcast that, you know, you chain all these things together. You keep finding, keep finding, and you chain them all together, these side quests. Do you think and this is kind of a loaded question.

Right? I'm leading the witness. Do you think having the ability to pentest for an extended, a very long time, is what gives us the ability to be able to do those types of attacks where we can chain things for a long period of time? And then once we learn those from one client, we can apply them to our, you know, other clients and see if they work there too. Do you think that's an advantage for clients who want our CPT service?

So I'll I'll answer that one. So I will say this particular attack path, I have used on internal traditional internal network penetration tests that I've seen other testers use. But when it comes to side quests, I do think that that is one of my favorite parts about being on this team is that you have the time to dive into the side quests. And I do think that that that brings a lot of value to the customer. It also allows us to let's say, we do something and we turn in a report about something and a customer has this insight that we do not have.

And it's like, oh, well, if you looked at this, that would have been a really big, really big issue. That one of those, the small things that lead to big things. We have time to go back and forth and work on those things. Caitlin spends a lot of time on the side quests for anti sock. Okay.

Yeah. So, Brian, if somebody wanted our side quest capabilities, what's the first step for them?

I mean, there's there's a lot of first steps you can take. There's a lot of all roads lead to Rome, I would say. So, I mean, you can reach out to consulting@blackhillsinfosec.com. You can do the contact us form. You could message me directly on Discord.

There are there are there are there are and which ones am I missing, Jason? I think there's there's probably a few more in there. You could reach out to Jason and Deb. Mhmm. There's a lot of things that you can do to reach out to us.

We try to make it as easy as possible, And we we don't dump you into a marketing email campaign that follows up with you every three days. I see Deb just sighed deeply like Yeah. Yeah. Yeah. So I would say that that, you know, the contact us on the website, reaching out to us directly on Discord, emailing, consulting@blackhillsinfosec.com.

All of those, they're probably really good answers. And you could even call. We have we have a phone too that goes to Logan Bender. You can bother him.

Mhmm. So once someone like, what's the onboarding process look like for the CPT? So maybe Caitlin and Alyssa, I'm not sure if you know what the onboarding process looks like. But let's say someone says, alright. Let's do it.

Let's get twelve months. What's first?

An ROE call.

Yep. Okay.

That was gonna be my guess.

And what does ROE stand for for someone who like

Rules of engagement. Just like any pen test. You get on a call, make sure everybody's on the same page. What are your expectations? What are your what are your no no areas?

What are your yes go there? Those are the absolutely what I wanna focus on. What's your market vertical is most concerned about? What are all those different places that you want us to focus on? Ignore.

You're concerned about what's keeping you up at night. Just making sure that, you know, what would make you happy at the end of the day, at the end of the year, what would make you happy with the engagement type stuff.

So do like, what is the level of maturity for a CPT client? Like, is this because I'm sure people are like, well, I don't think I'm ready for that. And maybe Yeah. What would you say the level of maturity is for a CPT client?

I will I'll give my viewpoint on this, and I'd like to actually hear Alyssa and and Caitlin's perspective on it. I would say if somebody came to us and they've never had a pen test before and they were like, I wanna do CPT, I'd probably be like, calm down. If they have if they're the only person at a, you know, a 2,000 person company that does IT and security, it might be a little hard to keep up to date on some things like that and just to keep on track of of of stuff. But, yeah, I would say it's kind of a crawl, walk, run approach. And I think I think the the CPT stuff is very much so like the the the walk to run to sprint type type clients.

But I'd love to get Caitlin and Alyssa's perspective on that what they're seeing from the current clients that we have.

Yeah. I would I would say that most of the RCPD clients are on the on the more mature side of organizations. And especially because a lot of times, less mature organizations will have more of those, like, low hanging fruit, those things that don't really take a lot of time to exploit, those things that are, you know, you can you can pick up in a in a three day, four day, five day test. Whereas the more mature customers, those are the ones that that need the extra time to to be able to provide more impact because they've already taken care of their low hanging fruit. So, I mean, a a less a less mature organization could definitely benefit from CPT, but it I think you it would it would be a lot a a fire hose probably.

If you if you have a lot of security issues, it would be a lot to to fix and keep track of.

Right. Yeah. Cool. Yeah. It's kinda like you get a free plane ticket.

Like, you you get value out of the CPT, but if you're not if you if you if you have a lot of low hanging fruit, we're gonna find it, but it's kind of like bringing kind of like bringing a nuclear bomb to a knife fight sometimes. Like, we'll get it. Well, yeah. Yeah. A lot of tactical things that we can do on, like, an internal, external, get the ball rolling then Mhmm.

Some compromise and then bring in the big guns down the road too.

Mhmm. Well, and, like, if at the if at the beginning of your your long term CPT contract, we find a whole mess of things that need to be fixed, it will be difficult for you to focus on the things further down in that long term contract because you're you're still trying to fix these things that were all discovered at the beginning.

Yeah. Okay. So let's say someone's listening to this right now and they're like, oh, I am not ready for CPT. What would their step be? Like, if they're they work in their operate

you know,

they work in security for their organization, and they're trying to figure out how do I get Black Hills to be our pen testing service.

Well, if they're not ready to do CPT, don't waste our time and leave us there. Yeah. Like, I would say, we do a lot of we do a lot of things. Even like we have companies that have come to us and they don't they've never had a pen test before and they're they don't necessarily have the budget for a pen test. And so they'll do, like, an atomic controls assessment.

Right? Just to kinda get our their our foot in the door to get the ball rolling. And that that's a cheaper that's a cheaper assessment. It's based off what our pen testers think are important. And then just kinda getting the ball rolling even with just an external, you know, starting with something like that.

I've seen so many customers that upper management is so willing to do unwilling unwilling to do, like, a full pen test. But they've gotten us to start off with just doing, an external, something that's very, very, like, entry level when it comes to pen testing. All of a sudden, they get some results, and they get some perspective, and it kinda starts opening the eyes of some upper management. And then the next thing you know in the next five, six years, they're doing full blown stuff. So I think kinda going back to, like, what Alyssa and Caitlin were talking about with with, like, you know, the smaller stuff, just just because you want, like, a CPT or the anti sock or you want, like, a full blown red team doesn't mean you you you you should have that right now.

Maybe, you know, get the buy in from management early with some smaller level engagements through us and things like that, and then get the ball rolling down the road and get get some get some get some acceptance of pen testing and then go from there. Let it grow.

Brian, are you you know, I never know how to answer this question. You can always tell me like,

what

is the price of the CPT for a year?

It's a $160,000 for the year.

So that doesn't depend on how big the organization is. We don't like channeling price based on how

I mean, unfortunately, I'm I'm the greedy capitalist in the group and and my family. And I've tried to convince Corey to do it otherwise. And Corey's like, I don't really see a reason to. So no. It's a 100 I think it's a $160,000 for the whole year.

I think we have some organizations that are like they have multiple different divisions, like so they're like a conglomerate, Mhmm. And they have like 10 different business units underneath them, or they have like multiple business units based off like regions.

Mhmm.

Trying to explain that without saying too much. And they need each an individual business unit. It kinda stands alone on itself, but it's all underneath the umbrella of a bigger company.

Mhmm.

And they need each and every one of them need to have individual teams. Those can start to be broken out. But even those, we start to kinda work with a bigger organization to basically be like, okay. You don't need a 160 each one. Maybe we'll have some modifiers and things like that.

K. So we do probably suck at capitalism. Yeah. A little bit.

It's my my best efforts.

Caitlin, Alyssa, what's been one of your favorite things you've gotten a chance to do on the CPT? And then we'll look to see if there's any, you know, lingering questions here that you guys haven't answered. But like, Caitlin first, what's been one of your favorite things to do for a client in the CPT that like you get giddy, I guess, brings you joy. I asked Michael Allen, it's the postcard for him. He loves the postcard.

Oh, that's so good. So good. I I I get excited more about, like, the the specific customer requests. So the the things that are not necessarily the the things that we would do for every customer, but the things that are like, hey. This is this is specifically what we're concerned about, or this is specifically, like, the kind of attacker that we think is going to be going for our organization.

Or maybe this is specifically the kind of attacker that has already targeted our organization. And I I think that that's fun. I think that it's fun to to look into, like, the specific TTPs of, you know, whatever their concern is and try to emulate that.

Cool. Alyssa, anything brings you joy?

My favorite thing is when you are using a certain technique and it's fruitful and it works and whether that's across, like, different customers or in a specific environment. And then then you go into the environment again, and they're like, can you test this? And then you can't do it. And then, like, figuring out but you can't, like, immediately into it why it doesn't work and, like, working with customers to see how different environments are set up and, like, why does this thing that typically works not work. Thank you.

Collaboration.

Yeah. Alright, Brian. Any final thoughts for why someone should hire Black Hills to, you know, either get them started in testing their security or continuously testing their security?

I would say I'm gonna I'm gonna I'm gonna answer the I'm not gonna answer that. What I'm what I'm gonna say is Tom, Logan, and myself, we don't work off commission. And I think a lot of the times and I talked with Tom and Logan about this a lot. The favorite part of our job is getting on calls with customers. And that and that's not closing deals, that's not pitching products, that's not pitching services.

It's literally just getting on the call and just talking to people about where they're at. And I think I'm not trying to say, like, hey. Call us up and tell us about your problems. You you know, if you don't if you're not looking to buy or anything like that ever. But I think for a lot of people, like, if you just you know you know, we've talked to a lot of companies.

I think we do over 2,000 sales calls in a year, and those are just all inbound. Those are people that wanna talk to us. We get a good idea of what we've heard that works really well and what doesn't work really well. So even if you're not looking for a pen test right now, maybe you're thinking about doing one next year, maybe you already got your your one picked out for this year, just get on a call and talk with us. Whether it's your SOC, whether it's you're thinking about CPT and you know you're you're years off down the road, it doesn't hurt.

It doesn't hurt us. It doesn't it doesn't upset us. We don't track metrics in terms of, like, we get beaten if we we fall below a certain percentage of win dollars. We don't care. So don't ever feel afraid to just reach out and set up a call and talk with us.

It is literally the favorite our favorite part of our job is to get on calls with customers and just b s with them about what they're dealing with, what they're going through, what they would like to see, what they wouldn't, what's been bothering them. And sometimes we have some weird kooky solutions that, we've heard from other customers that we can pass on even in the middle of a quote, unquote sales call. So that would be my number one thing of advice, is even if you're not looking, be willing to get on a call and just talk with us because we do not hard sell. We do not work off commission. We just we just enjoy talking with people.

Yeah. Thanks, Brian. Yep. Alright, Deb. Yes.

Director of kindness and generosity.

Yeah.

What would you like to say to the community as we sign off for today?

The same thing I say every time is just thank you for spending your time with us. There's so much noise out there, and I know I don't like to say that word noise, but we just really appreciate that you show up and and trust us. Trust us with your time. So we love you guys, and we'll see you next week.

Alright. That's it, Ryan. Let's kill it with fire. Kill it, Ryan. Kill it with fire, Ryan.

Ryan. Ryan,

we got, like, another meeting.