Pentesting Active Directory with techspence

0:00 When I was a pen tester, most of our engagements were on web apps, but occasionally I would do an internal network penetration test or a red team in those, you usually run into a Windows environment. And when you're in a Windows environment, you keep seeing the same intimidating word, which is Active Directory. And so I wanted to talk about that. And so we're here with one of the experts in Windows and Active Directory security. tech spence You're really talking me up there.

0:30 I don't know how I feel about that, but super happy to be here and chat with you. And I had to turn some of my lights on because I was watching videos of yours in previous podcasts. I'm like, man, he's got such like a cool background. Like mine is like, I'm still kind of like revamping it and stuff and trying to get it just right. But I had to throw a little LED light on to kind of fit the vibe here.

0:51 Looks good. I like the chair too. So I guess for an intro, you have your own podcast, YouTube channel. Can you talk a little bit about those? Yeah, yeah, so I through my work as who produces it secure it 360 I have a podcast and we mainly talk about security from an offensive security perspective So it's a bunch of pen testers talking about security topics But one of the things I think is interesting that we bring to the table is both me and my boss who are the most regular?

1:17 Hosts of that podcast both have experience in internal IT infrastructure security internal environments kind of corporate IT slash security So that ties into my background, which I think we'll get into, but I've kind of got like a wide range of experience in IT and security. So we can draw on some of those things to talk about security from a pen testing perspective. We've got like, I think we're at like almost 170 episodes now. We've been doing it for like four years or almost four years.

1:48 So every week it's been super fun, but as you know, like it's very much a grind and it's sometimes hard to keep up with. but I really enjoy doing it. And link will be below. So you're a pen tester now, but I wanted to start with your journey on how you got to being a pen tester. Yeah, absolutely. So I started in Help Desk. I've talked about that before. I think starting at Help Desk is actually super, super great from an IT, like, technical background.

2:14 So I started in IT. I got a computer science degree. In the short story, there is, like, I was going to be a doctor like my dad. And it was like, you know, I failed all the courses and I never went to class. I was playing wow instead. And then I was like, I'm going to do computers. So I did computer science and did all that. And that was super fun. But I started in Helpdesk, and Helpdesk was super great.

2:33 I moved up from there to systems administrator, IT admin kind of thing. So that's where I kind of got my feet wet with Active Directory. I was in Active Directory in a Microsoft environment, so I got to play around with that. I got to play around with the SANS and AS for hundreds and servers and all that jazz as an administrator. I got like a real appreciation for what it takes to run an environment, keep the lights on, keep stuff upgraded.

2:57 And then from there I went and I was in charge of security at that job and that everything, you my eyes were open to the world of malware and red teaming and pen testing and all that. And that was super fun. And now I've gone to the dark side in the last four years or so I've been doing pen testing, specifically internal pen testing. And one of the funny things I like to jokingly say is I'm very much a recovering sysadmin, meaning like, I was just talking about this the other day with my boss, I'm like, I honestly wouldn't hate going back to the IT world and doing IT administration with the right environment and the right incentive structure set up to do that.

3:32 So I very much adore IT administration and IT security. That's the world I come from and the I'm really passionate about. Yeah, so definitely some of the best pen testers I've seen started with a help desk or sysadmin background. So when you were doing that... was security like a common consideration during your job? Like how did you become responsible for security? Yeah, so I didn't really know what security was when I started Help Desk, as many security people or Help Desk people do.

4:04 I was fixing printers and resetting passwords in Active Directory, And helping users log into our insurance application that we had. So I was introduced to it in Help Desk, right? And one of the funny things I remember is I remember setting the same local admin password. across all of our devices. Like I remember doing that and I remember the password. Like I could recite it to you right now because I've memorized it. Right. And now that I'm doing pen testing that's so obvious to me as a bad thing.

4:33 But when I started out like I had no idea like it just didn't occur to me. And then we started we were an insurance company. So we were beholden to these requirements and regulations. Right. And being in New York we had a number of regulations. New York State DFS cyber was one of the big ones. and that said you had to do a certain amount of cybersecurity stuff. So it was like my first introduction to it.

4:56 Shortly after I was a sysadmin, like a few years into my help desk, like IT journey, there was all these new requirements coming out for cybersecurity. And then we had vendors come in and like do security assessments. And then eventually we did pen tests on ourselves, right? Like we had them come in and do pen tests. So that's how I got exposed to it. And it was very much like, All the things I say not to do now, I used to do.

5:18 Yeah, so Active Directory is a very complex system. It's difficult to learn and takes a lot of time. So how did you feel about your journey, like slowly learning about it, especially about all the security nuances of it? Yeah, one of the best things that I was fortunate enough to have was we had a little sandbox environment at my job. So we used that for a couple of things. One was for DR. So we had tape backups and we would take our tapes and physically take the tape and put it in the tanberg and like restore in this like it was a wire closet.

5:51 Like think of this like six by six room, no windows, just a door, right? Not a great environment to run like a one use server rack with a couple of things on it. Right. but we had this server or this wire room and that's where our lab was. We would recover and do our DR testing there. And we also used it as like a lab environment. So whenever a new security vulnerability came out or something kind of dangerous that we wanted to test, new deployment or an upgrade, we would test it in the sandbox or in the little lab environment.

6:20 So I was fortunate enough to have that. And I think that's a great. place to learn is like the safe environment that's a replica of your production environment to be able to test things in. Not everybody has that luxury. But also, I'd learn in production too, right? Like doing stuff and breaking things. One funny example is when I was first starting in security, I was doing vulnerability management, right? And it like, I'm gonna do vulnerability management.

6:43 I'm gonna get rid of all these high and critical vulnerabilities, right? So there was, Microsoft is MSXML4, right? And this was years ago, right? And it was deprecated and insecure and all that. And I'm like, I'm gonna be a go-getter, right? I'm gonna uninstall it from the server. So I uninstall it from the server and like 10 minutes later, you know, the admin for that box is like knocking on my cubicle and he's like, hey, did you do anything on, you know, app server one or whatever?

7:08 And I'm like, I just uninstalled this vulnerable software. He's like, well, we can't take payments now and we're losing like millions of dollars every hour. I'm like, man. So I learned a lot of lessons like that. Doing things the hard way and like not thinking through problems. in many ways, that's how you learn, right? Like we just reinstalled it. All was good. And company was back up and running. But learning in production is ultimately going to happen.

7:31 So it was it was good that I I had gone through those experiences. But learning kind of on the job and kind of Googling things and researching things as they come up is a really important tip that I would say is like, if you're not familiar with something, go look it up, go learn it. And that's what I did. And that's why I think I naturally gravitated towards the security stuff, because it was new and interesting.

7:52 The IT stuff, like I had learned a certain amount. So that was really pivotal for me. Nice, yeah. And so at that point, like you're learning about like how to secure an Active Directory environment and at what point did you realize that these problems are like across the entire industry? I didn't realize it until I became a pen tester. You know, like I was in my own little world, like at this IT job, this small, you know, small company in upstate New York, right?

8:19 And I had gone to some conferences and stuff like that, but I never really talked to a lot of people in the industry when I was at that job. It wasn't until I was a pen tester and I was seeing other environments where it clicked to me and it clicked on the first engagement. And I'll tell you this story. So I was doing an internal pen test, my very first one, right? I was doing like a writing shotgun with my boss, right?

8:41 He was kind of showing me the ropes and he like sent me off on this task, right? Like go do this thing. So I'm going and doing this thing and I come across this file share and this file share has an admin, a password, a text file with an admin password in it. And it's had username and the password like right next to each other. So like clearly, obviously together like this was the credential for the account.

9:02 So I use that account, I log into the domain controller, I take a screenshot, and then I emailed the client, like, hey, I found this password on a file share. And no joke, I kid you not, the client emailed me back. He's like, that's my thumb drive. I forgot to remove it. And I'm like, what? Like, your thumb drive? was like shared out to the network? Like, I just couldn't believe it. And then after that engagement, I go to my boss, I'm like, Brad, is this like what all the engagements are like?

9:27 He's like, yeah, like this is... you can expect a lot more of this. And that was my introduction to internal pen testing. And that's the moment I knew, like, I'm in for a ride. And then from then on, it was like, where are the patterns and the trends that I can find so that the next engagement I can help educate the next client or, you know, take the lessons that I learned from the previous engagements and pass them on to future clients.

9:49 So super fun. I love that. And so at that point you started realizing, you know, every environment needs a lot of work. Those trends, like what are some of the major trends you realized that like apply across most of your clients? Yeah, local admin password reuse is a big one in internal environments. know, fortunately, we're seeing less of it now that people are understanding that there's LAPS, local admin password solution to help randomize those passwords on all your endpoints.

10:16 So there's some really great solutions there for that. But local admin password reuse is a big one that we see credentials just kind of scattered about. That's another big one. It could be file shares, document management systems. It could be Wikis, like Confluence and ticketing systems. I did a pen test once for this big advertising company and they didn't have a lot on-prem, but they did have a lot of Google Docs and Confluence and ticketing systems.

10:44 It was just wide open access. I just searched for password on every one of those and pilfered hundreds of documents with passwords in them, API keys. So credentials is a really big one. And you can even look at, you know, data breaches and a lot of the big incidents have, they attribute to starting from like credentials on ticketing systems, SharePoint, file shares and stuff. So that's a big one. And then since, I 2021 or 2022, something like that, when SpectroOps released their research on ADCS, that's been a huge one.

11:16 That we see, you know, almost in every environment that has ADCS, we see some kind of issue there. So those are probably the top three, I would say, that are common across the board right now. And one thing, so in pen testing, one, I guess, challenge or pattern I had was that often you would read the report. You know, you try to detail everything you found, here are the issues, here's what you should fix. And then often you would come back like a year later and not much was fixed.

11:42 So is that also your experience and how usually do you like work with clients on like pushing for fixes? Yeah, it's not uncommon to see, unfortunately, that, you know, IT teams are just overwhelmed, right? Like they're keeping the lights on, they're upgrading their sand, they're upgrading their firewall. Like, shoot, there's a zero-day in our firewall. Should we like change from Fortinet to something else? And they've got a lot of projects and initiatives going on just to keep the infrastructure working and keep the lights on.

12:11 And most organizations that I see don't have dedicated security teams. And we work with medium to large size organizations, but even still, even in really big organizations, they don't have dedicated security people a lot of times, right? And that's one thing that's a challenge is getting these organizations to be able to remediate. So we take a lot of pride and effort and put a lot of emphasis on the reporting process. to make the findings as detailed as possible to provide evidence so that they know exactly what to fix and how to fix it.

12:43 But ultimately we can only go so far, right? We can't push the knobs and check boxes for these organizations. So we'll do as much as we can and many times retesting windows go months and months and months just to make sure and help the client. But the biggest factor I think in whether or not the organization can remediate is if they've made it a priority. There are small teams that I've worked with that have fixed findings in 30 days.

13:08 Like 20 findings, they fixed them all in 30 days. I come back, I retest, they're all fixed. And then large organizations of move out of snail space. There's a lot of different teams and there's a lot of collaboration that has to happen. So it comes down to many times just prioritization and being able to free up cycles for those people to fix those things. But that is a systemic problem. in pen testing and it's unfortunate to see and it's kind of like a bummer, it's a buzzkill and you come back to the environment and you look at last year's report and you just go line by line, like, oh, there's the admin password, yep, password reuse.

13:40 So it is unfortunate, but it's kind of the name of the game in many ways. Yeah, yeah, right. some pen testing companies, they offer like Staff aug, like the resources as Staff augmentation to the client to be like, hey, like we'll have like a full time resource for like, you know, six months or whatever to help you remediate. So I haven't really, I don't know if I believe it really works, but do you have any opinions on that?

14:08 Yeah, I think again it comes down to prioritization and how well they are setting aside time to work on those things. It's not uncommon for us to do a pen test and then to work with that client, like I said, over several months. We'll meet, we'll retest things, and we'll do it multiple times in multiple iterations to make sure those issues are fixed. It's obviously easier with the external stuff because you don't need access to the environment.

14:32 You just scan, you check it, you run... the payload again and you can test those things easily. With internal, it's much more of a lift for the IT team, right? You have to grant them access or grant us access. They need time to of babysit you almost to help go through those things. So there's big difference in external web testing than there is internal. But that being said, I think if organizations can devote time over a series of months and you meet with a tester, I think that it could be a really good opportunity for them to at least siphon the knowledge out of the pen tester to be able to address those things.

15:10 But I think it comes down to like the IT team. Are they going to dedicate a resource to be able to do that and be able to address things? And then a lot of organizations just don't have a lot of internal expertise. So even if you have a pen tester sit with them, you're kind of sitting with a non-technical IT leader and they rely on like an MSP most of the time. that MSP does a lot of their IT work for them.

15:31 So many times we're interfacing with the MSP to like fix things on their behalf and it can kind of get, you know, kind of wishy washy because of that. That's a really good point. Did you ever like see some sort of trend on like why, like what are some challenges your clients face on pushing fixes? Like what actually like blocks them from fixing or they sometimes tell you like, hey, like we can't actually fix, you know, for this reason.

15:54 Yeah, most of the time it's they don't understand the impact of the fix. So a good example might be like NTLM. We see this often where NTLM is at the level two in an environment. And because of that, if you get an NTLM hash, you can essentially crack that, right? Like you can use rainbow tables and it's essentially a guaranteed privilege escalation. if you're able to use rainbow tables and crack that, right? What I see a lot of times is organizations will ask us like, well, what's gonna break when we fix this, right?

16:23 It's like, well, I can tell you what typically breaks. I can't tell you specifically in your environment. And it's not exactly easy to go out and audit NTLM. Like you have to turn on some auditing features and then you gotta look at the logs and you know, it's just a lot of work. And you know, there's, you know, some people that are a little bit allergic to the work, right? I'll say it, call some people out here.

16:43 They're afraid of breaking things in their environment, right? Rightfully so. Like if they're a hundred million dollar or a billion dollar bank, like are they gonna flip a switch on Friday afternoon that's potentially gonna break, you know, their payment system? Probably not. So I think the fear of breaking production is a big one. The other one is experience and just expertise. Like they don't know what to fix. So this is really common with ADCS. I'm by no means an expert at ADCS, but I know my way around it.

17:09 I know kind of how to guide our clients and our customers on what could potentially break as a result. But a lot of the ADCS stuff is like, the vendor says to set it up this way, and if we change it, we don't really know what's gonna break. And we have to contact the vendor, but it's like, how can you get ahold of VMware to figure out what's gonna break if we change this certificate template? So a little bit of it is lack of experience or just expertise of knowing what to change and what the impact is there.

17:36 So I would say those are the biggest two. The third one is probably just time and resources. Like they might know what to fix. They know kind of how to approach the fix, but they're putting out fires and they just don't have time to go and fix it outside of like maybe the really, really, really critical ones. So they'll fix like the stuff that led to privilege escalation, but you know, they'll leave some of the harder to fix, like weak password policies or some NTLM settings or some of that kind of stuff that's more hygiene related.

18:05 They'll kind of ignore that because it just takes a lot of time and lot of resources to coordinate and collaborate on all that stuff. Yeah, that's a good one. So since you've been doing this for a while, one interesting thing about Active Directory is that even though it's existed for a really long time, it has actually changed quite a lot, especially in recent years, people have been moving away from on-prem into the cloud. So what have you seen in terms of changes over the years?

18:31 Yeah, I've definitely noticed a shift to hybrid, like hybrid setup with Entra. Most specifically what I'm seeing is one of two kind of shapes for organizations. The first one is they're just hybrid so they can get like Microsoft 365 and email and the Microsoft SaaS apps and typical SaaS of Zoom and like a lot of the online stuff. but a lot of their core identity and infrastructure and stuff like that, that's more closer to their core line of business applications, they're still keeping on-prem, and they're in a hybrid sync setup where the Active Directory is still source of truth and they're syncing to Entra, right?

19:12 The other one that's becoming more common is where they're hybrid and they're literally moving their core infrastructure. to the cloud, so they're using Azure or AWS and their endpoints are Entra-joined. No longer are they joined to Active Directory. Really the only kind of interface to Active Directory is like one or two things that they have to keep around because their legacy and like the vendor just doesn't have an upgrade path, you know, to put it somewhere else.

19:39 I see that a lot with universities where they've got applications like learning management systems and finance systems that are just kind of older legacy systems. These universities don't have a lot of money and finances to like upgrade those and get them into the cloud because there's different licensing models and you know vendors kind of make it difficult. So they have to keep those on-prem but they need the luxuries of cloud and SaaS and Entra. So that's where I see hybrid joined or Entra joined devices and still kind of having Active Directory left around.

20:12 The downside with that is that those organizations still will typically have like some sort of VPN or remote access into their Active Directory environment. And that's one of the things I talk about with them in a kickoff call is like, okay, if you're hybrid, like what does remote access look like to your environment? If every device has a VPN or if you have like VMware Horizon or something like that, I can still get in. which means assume breach, internal pen testing is still a very valid assessment.

20:37 But there are some cases where clients will come to us, like, hey, we want an internal pen test. And I'm like, cool, tell me about your environment. like, okay, our devices are Intune joined or Entra joined. Our Active Directory is just two DCs in a closet somewhere. There's nothing on-prem. What do you guys want me to test internally? Your Wi-Fi? What are we testing here? But those are the two most common cases. Yeah, which one feels like the most common?

21:00 Are people still using local AD heavily or are most being hybrid? Like, how do you feel? It kind of runs the gamut. I would say for financial institutions and kind of like more regulated industries, they are, I would say anecdotally moving more cloud, like more Entre-focused, more cloud, less reliance on on-prem with other industries like law firms that are typically less regulated other than like client requirements. They're more legacy on-prem, still kind of clutching to traditional Active Directory environments.

21:32 And then same with universities or just kind of smaller organizations, municipalities, kind of less resourced organizations are still very much relying on on-prem because Active Directory is free, it's included in Windows, right? Like there's a lot of potential cost savings that organizations see there as opposed to shifting everything to the cloud. smaller, less resourced organizations I'm typically seeing still kind of remaining on-prem. Nice. And do feel that generally the shift towards the cloud, towards Entra has been like a more...

22:04 Like basically it's been a shift more towards secure defaults. It kind of depends. So Microsoft has got their security faults in Entra, which is great. One of the most common kind of insecure things that I see is related to conditional access policies. So one of the things I'll do when I do purple teams is we'll test logging into their environment from different locations with the VPN and conditional access policies for whatever reason. I don't know if it's because it's like, You know, group policy is its own thing and it's like, it's a beast in itself and you kind of got to know how it works and understand it to be able to administer it correctly and securely.

22:39 I feel like conditional access is like this black box. It's like, either know how to configure it and secure it properly or you don't. I see a lot of organizations kind of making mistakes there with conditional access and not restricting the things that they should, especially with GVIL filtering and stuff like that. But I think one of the common misconceptions is that we can move to Entra, we can move to Cloud, and then we don't really have to worry about the security.

23:04 I think there's a group of folks that kind of think that, that like, we're good, we're secured. We don't have to worry about any of that stuff. But Cloud comes with its own challenges, right? It's a different, Entra ID is not the same as Active Directory, as you know, and there are many complexities to Entra. that you don't have an AD, there's things you don't have to consider, whereas you do an active directory. So the biggest kind of risk I see organizations kind of having to address when they move to Entra and move to cloud is it's a different skill set.

23:34 And when you move to cloud, you move to Entra, there's different things you have to worry about. And you have to have people that are knowledgeable and experienced in those things to be able to address those risks. I think a lot of people have quickly shifted to the cloud thanks to COVID and a lot of other factors, but they haven't kind of kept up with the skill set to kind of administer and secure that. Yeah. Yeah.

23:53 And so, and even from your perspective, assume like pentesting an AD environment versus like a company using Entra, like those are completely separate pentests, complete different things to look for and tools to use. yeah, for sure. And there's a reason that I really stick to internal Windows Active Directory. I know a little bit about Entra and Cloud and stuff like that, but I don't do web app pen testing. I don't do cloud pen testing. Don't do API and stuff like that.

24:20 I'm very, very much focused on internal Windows AD for that reason is because it's a very different skill set, right? And there's a very specific type of skill set that I'm after and that I am like to build and it's around Active Directory because you go on the deep end of Entra and it's like your eyes are open to all these wild things and it's very much different. Cloud and Entra and stuff like that is very much more similar to web and API pentesting than it is like Active Directory pentesting.

24:50 Yeah, Well, and luckily, I bet there's many more years of on-prem AD still being used. I don't think that's going away anytime soon. Yeah, think, you know, I've done, think it was like a thousand hours of pen testing, internal pen testing specifically, just in 2025. And I don't think, you know, I haven't seen signs of it letting up. So I would like to think that, you know, Active Directory is going to be around for a long time.

25:19 Microsoft did just upgrade the functional level to 2025. So there are signs that Microsoft is still interested in keeping it around. there's not as many new security features and enhancements as there were in the past. But quite honestly, I don't think we need a lot more from Microsoft at this point. I think the security and kind of the protection of that environment really comes down to the third party stuff and kind of managing the risk of what's there already.

25:44 I think we have a lot of the tools that we need to protect Active Directory environment. It's just... a lot of those tools are getting more expensive. Like EDR can cost you hundreds of thousands of dollars. A SIM and the log ingestion, like that can cost you a lot of money. know, Microsoft licensing, you go that route. E5 is very expensive if you're a big organization. So if we can, from a security perspective, you can control the costs of securing Active Directory and manage that.

26:10 I think it's still a very defensible type of environment. to have. Yeah, that's very cool. In terms of pen testing tools, so let's say someone is, you know, wants to get into pen testing, they're going to soon run their first ever internal pen test. What are like some of the main tools they should be familiar with? Yeah, it's a great question and to some extent it depends how you're gonna do the internal pen test. So for what I do, it's more of an assumed breach approach where the client gives us access to one of their devices.

26:38 So one of their Windows devices in their network and they give us access. So because of that, my tooling, kinda like my methodology and stuff is all focused around Windows endpoints. So a lot of my tooling is PowerShell, it's C-sharp,.NET stuff. kind of compiled stuff where I need it. But I rely heavily on PowerShell and C Sharp. So if you go that route, if you go kind of the assume breach route and you're pentesting from a client machine kind of thing, then some of the PowerShell-based tools that were really popular like 10 years ago are all of a sudden very relevant again, like PowerSploit.

27:11 I still use PowerSploit to this day. I think it's been years maybe, something like that. PowerSploit has been out or was released. and we still get a lot of value out of that. It's a great suite of tools. If you are kind of the Cali and kind of Linux type of pen test firm where you send a Dropbox and you deploy that way, then NetExec is like the Swiss Army knife tool. Like you just can't do pen testing without NetExec.

27:37 Like you can do it all the hard way, sure, but NetExec, formerly CrackmapExec, is a phenomenal tool. So that one I often use when I am doing like kind of more Red Team type stuff where the client does want us to come in through like a more typical remote connection kind of thing. So I will run Kali in like a WSL instance and I'll have a connection to their environment. So I will use NetExec there. So those are two that I would definitely recommend.

28:05 But some wild card are kind of like out there tools that I don't think people know could be used for pen testing, but ones that I talk about a lot. One is a deleg and a delegator. This is an Active Directory permission, Active Directory delegation management tool. It's free, it's super cool, and it just shows you the non-default delegations in an Active Directory environment. What's super cool about it is you just open it up and you can immediately find like, domain users has full control over the root.

28:32 It's like, you can find it in two seconds. It's super, super handy. And that's written in, it was written in Rust and now I think the author rewrote it in C sharp, but that's great. You just run it on windows on a domain joint system and it works. The other one is called net tools. Net tools is more of like a sys admin tool, which is probably why I like it. It's called the Swiss army knife of sys admin tools on their website, but that's a great tool.

28:54 has like a hundred or 150 different like little distinct tools in it. But I find that really handy for navigating Active Directory environments because the way I approach it is like I'm just like a temporary sysadmin, right? Or like my shirt says, I'm a guest domain admin in their environment and I'm trying to help find the issues in their environment. That's kind of how I tackle or approach internal pen testing. Nice, that's awesome. Do you ever find yourself using like Bloodhound to create like a map of the environment, like a graph?

29:24 I used to, I used to use Bloodhound on pretty much every engagement. The way we operate, because we operate on a client's Windows endpoint, it could be sometimes difficult to provide some evasion in the engagement. So one of the things that we do is it's like a mini purple theme. So we will do evasion, we will try to get around the EDR, we will try to kind of evade detection in their environment to an extent. When we use Bloodhound, it just lights up everything.

29:50 Like it's signature to death. And I haven't gotten around to really obfuscating in any way, shape or form. So that's the first reason is it's just like really noisy and it's hard to get running in most modern environments. The other reason is that I just get the data in other ways. So Adeleg, Pingcastle, Purpleknight, these are tools that are kind of flying more under the radar from an IT admin like threat detection perspective. So I use those tools to get kind of the same data.

30:17 It's a little bit harder. You have to kind of work a little bit more at it to get the same information. But we've developed a nice process to kind of like extract that same information out so we can find those attack paths and control paths in the environment without having to run Bloodhound. Nice. Yeah, that totally makes sense. Another tool that blew my mind the first time I used it was Mimikatz. You want to give your opinion on that?

30:41 Yeah, Mimikatz is great. I will usually use it. So here's the scenario, right? I've gone four days on an internal pen test, right? It's the fifth day. It's the final day of the pen test and the client hasn't sent me any alerts. They're supposed to send me alerts and like I will reconcile them with my notes. Okay, this was alerted. This was detected, blah, blah, blah. It'll be like the fifth day, the last day, the internal and be like, you know what?

31:03 I gotta find a way to get some alerts from this client. So I'll log into the domain controller and I'll... I'll drop Mimikatz on it and I'll try to dump NTDS.dit or I'll try to create a golden ticket or I'll do something that's like a DC sync or something that I have a high confidence that will raise an alarm. So I will use it for that. Outside of that, I don't really use it a ton because going back to the evasion discussion, Mimikatz is highly signatured even touching LSAS, SAM database in general, it's just, it's very noisy now and EDR products know, I have a pretty good job, they've done a pretty good job at detecting that kind of behavior.

31:43 So I tend to stay away from it unless I'm trying to like trigger alerts and stuff like that, at least early on. But it's a great tool, phenomenal, absolutely love it. It's like a, it's a staple in a pen tester's toolkit. Yeah. How many of your clients actually care about stealth and testing their own detections versus clients that say like, do whatever you want. I would say when we are talking to a client and we present to them like how we do internal pen testing, I would say pretty much 99 % of them always like that there is some form of threat detection involved in it.

32:17 And the reason is because a lot of times, like we said earlier, we were talking about earlier, how many customers come to us after an incident, right? There's a group of folks who come to us after they had an incident. So they know to a certain extent what their EDR is going to do and how that's going to respond. Right. They got alerts. They got the 4 a.m. kind of phone call like they've seen some of it.

32:36 But for many organizations the most they've seen is like B.E.C. and like somebody logged into the email account and like they haven't seen a ton of on-prem like attacker on the machine what that looks like. So we give customer we give clients is like okay, there's an attack around the machine, what is this potentially going to look like? What does the recon look like? What does it look like when they try to like elevate their privileges or move laterally?

33:01 So it's, called a mini purple team, but throughout the engagement, we're doing all these techniques and we're documenting them so that if something goes bump on their network, they kind of know what it looks like and they know what to look for. And that's, I think it's really beneficial to them. And I think it's a really important aspect of internal pen testing. Sometimes gets missed depending on how the pen test is done. But I do find that clients really like to see it.

33:24 And for better or worse, many organizations will use that to test their MSP. Right. They'll test their external sock to say, hey, this pen tester got in our environment and they did all this stuff and you guys didn't send us a single email. Like what gives. Right. Unfortunately, we get stuck in the situation where it's like, hey, the pen tester did this. You guys suck. And like you didn't see anything. And it's like, We're here to help.

33:46 We want to help both you guys. This is not a combative thing. We want to help you guys both get better. And we're not shy about that. But many times, customers will say, yeah, we want to test our SOC to make sure that they're going to catch this stuff. And I'm just curious personally, anecdotally, do you feel like the more successful SOCs have been external MSSPs or internal SOCs I have pentested against a couple organizations that have a really good internal team.

34:15 There's been only a couple of them. I can count on one hand how many organizations I've pentested in the last four years that have had a really good internal team. Outside of that, it's always been external MSP socks. I think there's just economies of scale there. To have the same level of sock internally would just cost too much. The tools will cost too much. The people will cost too much. So you do get some economies of scale there with outsourcing it.

34:41 The downside is, and I'm probably not saying anything new, but the quality of those external SOCs varies greatly. Like very, very greatly. Imagine like the AI automated pen test red team kind of platforms. It's like that, but for SOC, right? The quality and the skill level of these external SOCs and MSP. MSPs varies quite significantly across the board. Yeah, I mean, honestly, I've generally been in the favor of just hiring your own detection engineer.

35:12 The SOCs I've dealt with in the past, generally, they felt like it's just a duplicate secondary alert. Like any alert I receive from my tools, the SOC just like sends us the same alert again saying like, hey, we got this alert. It's like, yeah, I see it. like, there's usually not much more value. But you're supposed to work with them on like, you know, training them on how you want them to respond as well. But Yeah, a lot of them I've not been very impressed with.

35:36 And it's quite honestly, like I empathize because it's a very difficult industry, I think, or a difficult like specialty, right? I think out of all of the specialties in security, being a SOC provider and like doing threat detection, I think is the hardest. Hands down, it's harder than red teaming, it's harder than blue teaming, it's hard in being a sysadmin. Threat detection, I think is the hardest job because you're the first to blame and like you're it.

36:01 Like if you don't catch it, like the... the threat goes undetected and then like then what? So I do empathize. I think it's a really difficult specialty and it's a specialty or an area of security where there's a lot of new people, which means the skill is just not there for most organizations, right? It's an entry. It's considered an entry level position and it's staffed that way most of the time. And all of the top talent goes to like the really big firms, like the crowd strikes and stuff like that.

36:33 And then everybody else has kind of lesser skill, lesser talent for lack of a better way of describing it. So there's aspects of that, unfortunately, that kind of play into this. But I do think it's a very difficult thing. I wouldn't want to be a sock analyst or run a sock. It's very difficult. And it's almost better now. I'm thinking like there's some companies that are doing like AI sock. Again, might, if you're just gonna get an alert in an email, like maybe it's just better to have some sort of AI sock thing running in the background as your threat detection that can run through Gemini or whatever and give you some analysis, at least that's something.

37:08 And maybe it's just half the price of an actual external sock. But I agree with you, if it were me, like as an IT director or something like that at an organization, I would have like one or two people and they would run my threat detection. And that would be kind of like my starting point because you know the environment, can tune things quicker, they can respond faster. So I would much rather have it internally, even if it's just a couple people.

37:33 But financially, it's many times just not affordable for some organizations. Yeah, yeah, think you're at your own point. Just before we move on from tools, there's one more very important tool that you forgot to mention. And I think you recently wrote your own tool. You're talking about like app locker inspector or scripts entry you're probably talking about scripts entry Yeah, so Yeah, I mean all of those. Yeah, it's funny because I did quite a bit of research on logon scripts a couple years ago because I noticed that, you know, pink castle is great, but it only finds a certain type of logon script issue where everybody has control of the logon script.

38:13 And I'm like, surely there's other issues here. So I did a whole bunch of research and I did, I released a tool called Scripts Entry that finds misconfigured and dangerous logon scripts. The downside is it, It is a common issue, but it's not as common as other things like ADCS. And that's another tool I didn't mention, Jake Hildreth's tool, Locksmith. Locksmith is a free tool to audit ADCS. Those issues are way more common. The logon script issues, I see them here and there, but they're not nearly as common as other issues.

38:40 So that's why I didn't think of it to mention it, is like... I'm seeing it less and less, especially now that organizations are going hybrid and they're relying less on logon scripts. Or maybe it's just me yelling at them that don't use logon scripts, just use Group Policy or Intune or your RMM or something, MDM. So that would be the other one. But ADeleginator, which I mentioned a few minutes ago with that delegation stuff, that one I did write, but it's just a wrapper around ADeleg and it extracts information out.

39:09 So those are super good. That's awesome, yeah. And actually, I just remembered one last one we used to use sometimes on internal netpen It's probably very noisy, but responder, just like a Python script to catch NTLM hashes, is that something you still use? Yeah, Responder is great. I will still use impact it. will still use, so for Responder, I will use, if I'm on the Windows environment, I'll use the Windows equivalent. And so that's super good.

39:39 But Responder is really good. It can be, because of the way of accessing the client environment, it can... not be as efficient as being on their network because of the network and being on the same network in order to capture those hashes. So that can be difficult if you're working through a C2 or if you're kind of proxying the traffic in, you gotta jump through some hoops. I've actually been working on developing my own kind of like tail scale mesh VPN setup for clients so that I can use the traditional pen testing tools like NetExec and Impact It.

40:13 As a matter of fact, just a couple of weeks ago, I was testing an ESC8 relay vulnerability or misconfiguration with ADCS, and I was doing it over a tail scale tunnel into the client's network. But the amount of hoops that you have to jump through, like on Windows, SMB is already under control, right? So you have to stop SMB and you have to take over the port and you have to redirect the traffic. And there's just like a lot of hurdles you have to jump through.

40:38 to be able to carry those things out. Which is why I think like those relay attacks are less interesting to me as like an attacker. Because if I could just Kerberos or find credentials or you know, abuse misconfigured permissions or something like that, I'd much rather gonna do that as an attacker than you know, set up this complicated like C2 and relay kind of thing to carry out this attack. Still viable, but just a lot more setup involved in.

41:04 Nice, very cool. So earlier you mentioned that like some SOCs might start using AI to help them in response. And I guess that's a good segue into just how has AI been affecting your work? Yeah, so the main thing that I'm concerned of with AI is the data privacy and security implications of it, of using it with client data or in the client environment, which we don't do. And I would recommend no one do it right now on client data.

41:32 Even prompting and stuff like that, potentially you could run into some issues. Externally, web and API and external pen testing is a different beast, right, because it's external, it's on the public internet, so it's already there. But for internal, I don't use it like for task-driven stuff internally, but where I will use it is I'll help it, it'll help me be more efficient with specifically reporting. So I will take data from my notes and I'll use that, and it's already anonymized because I'm not putting like client data or it's like, you know, responder at the such and such time or whatever, you know, the notes will be.

42:10 And I'll use it to summarize my notes and like kind of capture all my notes to easily put it in a report. So that's one use case where I find it incredibly useful is like, I've got all these notes, these timestamps and like, you know, chicken scratch and like all of these different things that I'm doing on the engagement. And I just need to organize them in a presentable way. So that's super helpful. You just give it to chat GBT or whatever and like, it spits out in a nice format.

42:34 The other area that it's helpful for me is, you know, like, I'm not an expert at PowerShell, I use it all the time, but I'm like, I'm not an expert. So I'll have Grok specifically is really helpful at this. I'll have Grok whip me up a quick script, rather than take 30 minutes for me to write it myself, which I could do. like Grok, write me a script to do this and like this very specific thing.

42:56 Because a lot of times I have scripts like, pre-made for a lot of the stuff I commonly do. But in those one-off scenarios where I'm like, I gotta do this specific thing, I'm just gonna give it to Grok and have it spit it out, sip my coffee for a minute, tweak one thing, and then I will look it over and check it and make sure it's good, and then I'll use that. So that's been super helpful.

43:15 The last area is once in a while we'll come across a vulnerability where we do want a proof of concept exploit for. I did this a number of years ago when chat GPT first came out. I wrote an exploit in like C++ It was for the splash top software Somebody had found a vulnerability, but they didn't really spoof for concept code I just fed it to chat GPT and like in an hour. I made an exploit for it I didn't need to do it.

43:38 It was just fun in it like chat GPT was like, you know first announced like let's see what this can do So I made it an exploit for him like this is cool. So once in a while use it for that so if we see like a a piece of software typically on the endpoint, right? Third party software, it's got a vulnerability and it's got some details out there on like the NBD or whatever. We'll feed that to Grok or something like, can you make an exploit for this?

44:02 See if we can get this local privilege escalation flaw to be able to be exploited. It's helpful to show proof of concept to the client to say, you know, this is vulnerable software or, you know, this is vulnerable and it's exploitable, right? there's a big difference there. And it just helps the client prioritize. Like if it's actually exploitable and I can elevate privileges, like, yeah, I should pay more attention to that as opposed to just out of date Chrome or Adobe or something like that.

44:29 So those are the three areas I find it most useful. Lately, I've been vibe coding a lot or sorry, agentic engineering a lot. And that's super helpful just to scratch itches you have. You know, if you have an idea or something and I'm not a developer, I can code and I learned coding in college. So I have some, you know, I can work my way around the command line and code and stuff, but I'm not a developer.

44:51 But to be able to have an idea and just be like, spit it out of your head, be like, build this is like really empowering. So building proof of concepts of like ideas you have and like just scratching your own itch has been super fun, but nothing that I've used in like production or on engagements yet or anything like that. Yeah, awesome. Yeah, I'm a fan of using them for coding. Yeah, I just any skill that I can find I just immediately copy and paste it into Copilot and I just use it outright like I don't even I don't read it That's a joke for Zach.

45:20 So Cool. many people who talk to me who say that they want to get into security, they often say like, I want to get into pentesting. And then they're like, well, how can I get into pentesting? And so what is some advice that you would have for them? Yeah, my advice is be really sure that it's pen testing that you want to do because most of my time, like I spend 30, 40 hours a week or so in an environment and then 60 hours in consulting and working with a client, emails and communication and all that other stuff, R &D and like, you know, updating tools and, you know, fixing...

46:05 issues and tools and recompiling stuff and working on all of the stuff that's not actually hacking and like hacking AD and pen testing and all that. Majority of your time spent pen testing is typically consulting and client facing work. So that's the first consideration is if you want to get into pen testing, make sure that you're interested in that aspect of it. Unless you go like to an internal team, right? If you're working internal on a team, it's very different.

46:29 And it's a very different kind of environment. So that'd be my first. Yeah, exactly. If you're on an internal team, like you don't have your client is your boss and like your team and your organization, very different. So that's the first piece of advice around pentesting. The next is like, you know, the question I get often is like, how do I know what I am going to like security? Like I know I want to get into security, but I don't know what my advice for that is to just try different things.

46:53 Right now we have the luxury of having Hack the Box, Try Hack Me, a variety of different CTFs. And we have like a bunch of people who are very active on YouTube and social media that are talking about the things that they're doing. Like John Hammond and Network Chuck and all of the different people and you and Zach and like there's a lot of people that are talking about the things that they're doing. My advice is go try things on Try Hack Me and Hack the Box.

47:18 Like actually play with things. Do you like, you know, running NetExec and like... working on a command line and doing that kind of stuff. Do you like looking at logs and looking at patterns and trying to find trends and maybe you're more suited for detection engineering or threat hunting, that kind of thing. So try different things and figure out what resonates with you the most. Watch YouTube videos and content from people. And I think if you pay attention to it, you'll kind of naturally gravitate towards something like, I really like browser extensions or I really like this AI-agentic skills, like AI development stuff, and that's the thing I want to go to, right?

47:53 So that's my advice is like taste different things, try different things, see what resonates with you. And then once you find the thing you like, go like all in on it, like do as many CTFs as you can do, like dive deep into it. And I think you'll find that that's like a really good way to kind of discover what interests you or maybe none of it interests you at all. And you're like, I'm just gonna go be a veterinarian or something.

48:15 I don't know. Totally valid. Texpens, thank you so much for all of your insight. Where can people find you? I'm most active on X at Techspence is my handle on there. And then kind of like all my content spews out from there. I have a small YouTube channel and I post on LinkedIn, unfortunately. But yeah, if you just look for Techspence or Google me, I'm usually on most of the big platforms anyways. Very cool. Thank you for coming.